anyweb

but are you testing on windows 10 1909 with the may update ?

probably to add an additional layer of security to the CA, as the OCSP and CRL's are on an internet facing server whereas the CA is not

thanks for posting the solution so others will find it !

Management Points are for getting policy (and sending state messages), distribution points are for downloading your apps, updates, os and so on, so is your issue that users are download from the wrong DP or communicating with the wrong MP ? have you enabled Preferred Management Points ? attaching logs from a client with the issue would greatly aid us here in understanding your problem

i'm awaiting results from the user but will post here once i do where are you seeing the problem exactly (location wise) and is it an office network or home internet ?

this is what I got from Joe @ Lenovo https://forums.lenovo.com/t5/Enterprise-Client-Management/Windows-defender-scans-cause-100-CPU-usage-on-P1-Gen2-model/m-p/5018214 For my next test, I patched the 1909 factory preload with the May 2020 cumulative update. After doing this, I could not reproduce the problem. i guess it's your post also ? have you tried this ?

To receive a guaranteed $25 Amazon voucher, sign up to a free trial of Altaro Office 365 Backup and answer these two questions correctly! Which 4 different restore options are available for restoring Mailboxes? Which 3 different granular restore options are available for restoring Sharepoint files? What are you waiting for? Register for your FREE Trial, answer the two questions correctly & receive a guaranteed voucher. Submit your answers via email to win@altaro.com. Closing date: 9th of July 2020. Good Luck! T&C: One entry per participant, only correct answers will be considered eligible. Please note that this is only open to new Altaro Office 365 Backup triallists.

and you are seeing it only on ThinkPad P1 Gen2 ? have you looked into any of the bios settings to see if enabling/disabling anything secure related (for testing) changes the behaviour ?

are you also using the same version of Windows 10 as the original poster ? have you tried a newer release (like 1909 or 2004)

are these Lenovo's patched up with the latest BIOS and firmware updates ?

Introduction This blog post is basically my own troubleshooting flow after a recent Autopilot failure at work. The failure was linked to application installation and the cause was interesting. To verify what was going on I compared a failed Autopilot logs with a known good Autopilot log set side by side. The test computer at my desk consistently succeeded with Autopilot, while the users computer consistently failed during the Enrollment Status Page phase. I will explain what’s happening in the log to give you an overview how to troubleshoot it yourself going forward. Looking for clues in the logs The log in question here is the IntuneManagementExtension.log found in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Here is the section from the IntuneManagementExtension.log where it detects apps required for the ESP (Enrollment Status Page). This is taken from the failed Autopilot machine and at this point everything looks OK. Here is the same section from a known good Autopilot session. The log then adds info about each of these apps to the registry On an Autopilot deployed pc (or intune managed) you can find these registry entries in the following location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\Win32Apps\{USER GUID}\{APP_GUID} The USER_GUID will more than likely be different on each computer unless the same user is used on both computers. In the below screenshot I've expanded the USER_GUID to reveal several GUIDs that match Win32 applications installed on that computer. The ESP (Enrollment Status Page) set’s the status of each of these apps. [Win32App] CreateNewInstanceForWin32App setting appInstallState NotInstalled with userSID for Win32App_3dfa3b3b-83a4-4ed9-a7cf-a8376136ab26_1 And after some logging it starts processing each application in turn, notice how it now shows the app GUID and the apps friendly name, including whether there are application dependencies or not. The starting process for each application logging starts with the following line. [Win32App] ExecManager: processing targeted app The log then sorts out what it’s doing in steps such as below for each app. [Win32App] ===Step=== Start to Present app 3dfa3b3b-83a4-4ed9-a7cf-a8376136ab26 [Win32App] ===Step=== Detection rules [Win32App] ===Step=== Check applicability [Win32App] ===Step=== Check Extended requirement rules [Win32App] ===Step=== Check detection without existing AppResult [Win32App] ===Step=== Download [Win32App] ===Step=== ExecuteWithRetry [Win32App] ===Step=== Execute retry 0 [Win32App] ===Step=== InstallBehavior MicrosoftEdge, Intent 3, UninstallCommandLine STABLE [Win32App] ===Step=== Detection rules after Execution [Win32App] ===Step=== Set ComplianceStateMessage with applicationDetectedAfterExecution [Win32App] ===Step=== Set EnforcementStateMessage All those steps above should describe the process from start to finish of each required app within the ESP. According to the log, this application installed correctly, and the application type was .bin as this app is Edge Chromium and Edge Chromium is treated differently to ‘normal’ Win32 applications (.intunewin). Next it cleans up the staged content and verifies the installation state and finally checks if the ESP is finished yet, if not it progresses to the next app. So the first application installation was successful, which is great. Let's move on to the next app in the list, and it’s Chrome as revealed in the log. Proceeding through the steps we can see that it fails in the ===Step=== Download phase Just for comparisons sake, let's compare that failure section to the same section from a working machine What do the errors mean ? The app install fails with the following error line: JobError callback (Context: BG_ERROR_CONTEXT_NONE; ErrorCode: 80072EFD) for job 4abe5657-ae62-41be-8a3b-2f88e7f460cc Looking at the first reference, a search on the internet for BG_ERROR_CONTEXT_NONE brings me to these Microsoft doc links https://docs.microsoft.com/en-us/windows/win32/api/bits/ne-bits-bg_error_context https://docs.microsoft.com/en-us/windows/win32/delivery_optimization/bg-error-context And strangely BG_ERROR_CONTEXT_NONE translates to… no error: BG_ERROR_CONTEXT_NONE An error has not occurred. But the second error code is indeed an error.. Job has failed. Error: 80072EFD Job 4abe5657-ae62-41be-8a3b-2f88e7f460cc (BG_JOB_STATE_ERROR) failed to complete, cancelling... Using the Error Code lookup ability in CMTrace, I checked the 80072EFD error code and it translated to: Looking for clues in Endpoint Manager Looking in Microsoft Endpoint Manager, for the device in question and then selecting Managed Apps, and typing in the name of the application clicking on the Chrome app that failed I can see the following. Clicking on Show details should reveal some more information. And this does indeed sound like either a network problem (see first message) or quite possibly a Background Intelligent Transfer Service (BITS) related problem. BG_E_ERROR_INFORMATION_UNAVAILABLE (0x8020000F) Error information is only available when the state of the job is BG_JOB_STATE_ERROR. The error information is not available after BITS begins transferring the job's data or the client exits. https://docs.microsoft.com/en-us/windows/win32/bits/bits-return-values Back to IntuneManagementExtension.log log, I looked for the next app installation attempt, and the app was Cisco WebEx Meetings, a Win32 app. [Win32App] ExecManager: processing targeted app (name='Cisco WebEx Meetings', id='6e1e9458-26ba-406a-bdc6-2a27dc3ec905') with intent=3 for user session 0 And just like with Chrome, this app again fails to download. further down in the log I noticed this nugget... Exception occurs when downloading Win32App user session 0, the Exception is System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it xxx.xxx.xxx.xxx:80 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) Wait what ? No connection could be made because the target machine actively refused it xxx.xxx.xxx.xxx:80 So using whois I traced the IP address in the log and it turns out to be a Network services (telecommunications) provider. A content delivery network.... pulling more data out of the log relating to the actual content it was trying to download (and from where...) and checking swdb02.manage.microsoft.com revealed that the IP address blocking connections also belongs to Microsoft... I'll update this post with further information later if we determine why that content provider blocked the download of applications causing the ESP to report a failure. Summary Sometimes you have to really dig into the logs to determine where the failure actually occurred, I hope this gave some clarity of the process. cheers ! niall

no worries at all, thanks for trying out my guides, i'm happy for the feedback (oh and i still need to make that edit, so thanks for reminding me)

sure it will work, but you might have to do additional tasks, i will modify the two parts that refer to this and point out that if you don't run the PowerShell script to automatically create users and ou's, that you'll have to do that manually otherwise other steps may prompt errors. I already tell users to manually create the users, but i didn't mention to manually create OU's, i just assumed they would understand that based on the screenshots, I'll update it. thanks for your two cents.

i feel your pain, if you'd like to pm me some numbers of users affected i can ask Lenovo Engineering to take a look cheers niall

have you tried reinstalling the configmgr client agent on some of the problem devices? have you also verified that the clients have received the certificate(s) from your group policy ?

Introduction Microsoft recently release the mother of all Technical Previews, TP2005 with so much amazing cloud friendly content, and in this blog post I want to look closer at task sequence media support for cloud-based content. Here are the instructions for getting it going (and of course you’ll need a working CMG before starting this). Enable the following client setting in the Cloud Services group: Allow access to cloud distribution point. Make sure the client setting is deployed to the target clients. For more information, see the following articles: How to configure client settings About client settings – Cloud services For the boundary group that the client is in, associate the content-enabled CMG or cloud distribution point site systems. For more information, see Configure a boundary group. On the same boundary group, enable the following option: Prefer cloud based sources over on-premise sources. For more information, see Boundary group options for peer downloads. Distribute the content referenced by the task sequence to the content-enabled CMG or cloud distribution point. Start the task sequence from boot media or PXE on the client. Ok once the above is done and you have distributed your content for your task sequence to your CMG, PXE boot a computer that will get an IP address that falls within the range defined for the boundary of your CMG. As you can see above, this IP address falls within the boundary of our CMG boundary. It will first download the policy of your task sequence(s) from the local management point (not the CMG), but as soon as you start the task sequence and it needs to download content, you’ll see messages within smsts.log revealing this provided that your task sequence content is indeed on the CMG. Look for lines that read Found location https://<YOURCMGNAMEURL>/downloadrestservice.svc... and IsCloudDP = 1, PreferCloudDPOverOnPrem=1 later it starts downloading the content !, noticed that the prioritized location is your CMG including drivers…(much slower than downloading from a local distribution point though…) then downloads and installs the configmgr client agent, again from your CMG Now isn’t that awesome ! cheers niall

Introduction Configuration Manager technical preview version 2005 is out and here’s a look at some of the features. This is one amazing release, so many great features ! Tenant attach: Install an application from the admin center You need the following setup.. Enable the optional feature Approve application requests for users per device. For more information, see Enable optional features from updates. At least one application deployed to a device collection with the An administrator must approve a request for this application on the device option set on the deployment. For more information, see Approve applications. User targeted applications or applications without the approval option set don’t appear in the application list. In the Admin center, locate your device and click on Applications. If your application matches the pre-reqs above then it should be listed. Click the app will bring up options to Install or Retry installation. In addition, it will list the status of whether it’s installed or not. After clicking Install the app should install (or display an error if something went wrong). Totally awesome ! read the rest > https://www.niallbrady.com/2020/05/30/microsoft-endpoint-manager-configuration-manager-technical-preview-version-2005-is-out/

ok I got a reply and this is it..(in relation to your screenshots) the advice was that you should raise a support request with PSS and see what they advise, if you want me to push it forward then pm me the case number cheers niall

i havn't got around to this yet, maybe this evening, sorry for the delay Peter

on the server side, did you add the CMG connection point ? and did you enable the SUP and MP settings for Internet communication ? and on the site server, do you see any errors in your CloudMgr.log ? Once the CMG and site system roles are running, clients get the location of the CMG service automatically on the next location request. Clients must be on the intranet to receive the location of the CMG service, unless you install and assign Windows 10 clients using Azure AD for authentication. You can speed that up via restarting the sms_agent_host service

I've asked a PM in Microsoft for comment on this, it could be that your vpn solution is blocking some communication between the clients and the MP, but let's see what he says

start by checking step 5 here

i'm not sure what you mean by this, this guide is about installing ConfigMgr, and doesn't necessarily cover customizing client settings...

hi Peter what DO settings did you configure, I can verify in one of my labs cheers niall

The current uptick in remote work is resulting in numerous organizations shifting to cloud platforms in order to manage and secure their endpoints. Tech giants like Microsoft have also come up with solutions like Endpoint Manager and hybrid System Center Configuration Manager (SCCM), which combines the features of SCCM and Microsoft Intune, to help users make the best of both worlds. However efficient SCCM is in managing endpoints, third-party application management is its handicap. With hybrid SCCM enabling users to integrate with Microsoft Intune, they should be able to patch third-party applications in Intune as well. Patch Connect Plus integrates with SCCM to solve this problem, and facilitates seamless third-party application patching with its newest feature: Intune Application Management. This blog will discuss in depth how to configure and deploy third-party applications in Microsoft Intune using Patch Connect Plus. Configuring Intune application management in Patch Connect Plus The following steps help you configure Intune application management in the Patch Connect Plus console. 1. Register a new application in Azure AD The first step is to create a client ID and a tenant ID in Azure AD. Navigate to App registrations and click + New registration. Once you have provided a suitable name and configured the account type according to your requirement, click Register, and your application will be registered with a unique client ID and tenant ID. 2. Add API permissions to the registered application The next step is to provide adequate permissions to the application created. Click + Add a permission. Under Application permissions, click DeviceManagementApps and enable DeviceManagementApps.Read.All, DeviceManagementApps.ReadWrite.All, and Group.Read.All. Once that's done, grant admin consent to approve the permission, and select Yes whenever prompted for consent. 3. Create a new client secret Navigate to the Certificates & secrets tab, and create a new client secret. Give it a suitable description, and set the client secret to Never expire. Once the client secret for Patch Connect Plus has been successfully created, copy and save the secret key to a secure location for any future use. 4. Intune configuration in the Patch Connect Plus console Copy the unique client ID and tenant ID. Navigate to Patch Connect Plus' web console > Admin> Application Mgmt Settings > Intune Configuration. There, paste the client ID, tenant ID, and the client security details, and click Save. You have successfully configured Intune application management. The next step is to deploy third-party applications. Deploying third-party applications using Microsoft Intune Let's take a look at how to deploy third-party applications in Intune using Patch Connect Plus. 1. Open the Patch Connect Plus web console > Application Management > INTUNE. Select the third-party application you wish to create. You can customize the deployment using scripts, then click Create Application. 2. The selected third-party application will appear under Client apps as shown below. 3. The next step is to assign a group under the enrolled devices for the application created. Under Properties, edit Assignments and click + Add group. Once the group is added, click Review + save. 4. Once the groups have been assigned and saved, you can find the application created listed under the Apps section in the Company Portal. Click the application and install it as shown below. You have successfully created and deployed third-party applications in Intune using Patch Connect Plus. As you can see, setting up and configuring Intune application management in Patch Connect Plus is a simple process, and requires no additional infrastructure. With Intune settings configured, you can now create and deploy third-party applications in Microsoft Intune using Patch Connect Plus. Try the 30-day free trial to get a hands-on experience of this feature and much more.