Category Archives: SCCM

Configuration Manager can’t connect to the administration service

The configuration manager console can’t connect to the site database through the administration service on server

I am looking to test out one or two features which rely on MECM’s Administration Service so was somewhat disappointed when I got the error above whenever I clicked on the respective nodes. Mine is a fully PKI environment and my initial suspicion was that it was certificate-related. Having spent several hours tinkering with the certificates and messing with IIS and getting nowhere I decided to sleep on it…

The first thing I noticed was that the SMS_REST_PROVIDER.log hadn’t logged anything for over a month so something must be broken. I went to the SMS_REST_PROVIDER component on the server with the SMS Provider role and noticed I was unable to query/start the component. Looking at the status messages, it was constantly trying to reinstall and failing. A little more detective work and I found a possible lead to DCOM security, so I opened DCOMCNFG, expanded Component Services, expanded Computers, and then expanded My Computer. First red flag I saw was that there was clearly an error ‘bang’ on the My Computer icon. Anyway, I persevered and right-clicked it and selected MSDTC whereby I got an error:

“The remote server has been paused or is in the process of being started.”

This lead me to another post which was talking about a cluster configuration which was receiving the same error message. This got me thinking…I don’t have a cluster, what’s this on about? Anyway, I went back and checked the MECM box and it transpired I did have an old cluster I’d set up ages ago which I’d forgotten about and had since deleted one of the nodes! This was no longer required, so I simply ran a couple of Powershell commands:

Remove-Cluster -force

Remove-windowsFeature failover-clustering -restart

After restarting. I checked DCOMCNFG and the My Computer icon no longer had the bang in place. Nice. Looked at the console but still no joy. It was still telling me the Admin Service was unavailable šŸ™

I nonetheless sensed I was close. I went back to the DCOMCNFG applet and went down to the Distributed Transaction Coordinator node, under which there is another node called Local DTC. I right-clicked this and went to the security tab. I was interested to see whether the DTC logon account was correct. Unfortunately, it was (it should be NT AUTHORITY\NetworkService by the way). Another dead end. This time however I tried selecting the Network DTC Access check box. and opened up the MECM console again. I clicked on the Console extensions node and this time there was a short pause and everything appeared!

One weird thing I noticed. I was able to uncheck the Network DTC Access check box and my admin service seems to remain in place without error. I will monitor this but seems that it just needed temporary access here from my observations at present.

UPDATE:

Following the above, I found that a remote console I was using kept crashing. I had to add the Network DTC Access check box before it would load correctly. Further, it appears this checkbox should be kept checked as the console will begin to crash again when opened without it over time.

XML Parsing Error at line XXXXX char : Operation Aborted: MaxXMLSize constraint violated

Been a while since I last posted but ran into an issue today that had everyone confused as it quite a tricky one to track down. There had been a number of changes in the environment over the last few weeks so each and every one one of them was examined in microscopic detail. Let me explain…

We started to see a few hundred or so machines start to fail on a certain application (actually it was just a simple Powershell script packaged as an application) during the OSD build task sequence. As it happens this app was part of a nested TS but this is probably irrelevant. In any case, some machines were fine, others were failing. Nobody had touched the app in any way for several months.

After much digging and many red herrings, tucked away in the SMSTSLOG.log was the following message :

XML Parsing Error at line 473689 char 52: Operation Aborted: MaxXMLSize constraint violated.

The cause of this error was down to ‘too much policy’. Basically the affected machines had a lot of Defender Updates deployed to them and it was essentially too much for the machines to handle. Once removed everything started to work again.

If you’re pulling your hair out and can’t figure out why something is failing, then there are thousands of possibilities, admittedly. But it might be worth a quick search for the words XML Parsing Error.

Script Status Message queries!

If, like me, you spend more than your fair share of time searching through status messages to figure out what broke in the deployment over the weekend, then you’ll know what an arduous process it can be putting the criteria into each query. If you have a good few machines to check then you literally spend half your time typing in machine names and times.

Well no more, because did you know it is perfectly possibly to script this? Status Message Viewer (statview.exe) is simply an executable and with the right parameters and the correct time format applied, you can simply call the status messages from as many machines as you see fit (although I’d recommend you limit this to no more than 15-20 at a time).

One observation when running this against multiple machines is that you’ll notice some of the status messages won’t always contain as much info as you expect – simply refresh the status message and all info will display as expected.

Finally, create a text file containing a list of the machines you wish to take status messages from and use the path as a parameter along with the date from which you wish to obtain the messages, in the format YYYY-MM-DD.

Please note this script assumes you have installed the ConfigMgr admin console on the machine on which you run the script, and in the default location. If you have installed it elsewhere please change statview.exe path accordingly.

Param(
 [string]$path,
 [string]$date
 )
If($date -eq "" -or $path -eq "") 
 { 
     Write-Host "File path and date must be supplied as a parameters.
     Example: 
     -path C:\Temp\Computers.txt
     -date 2021-04-09"
     exit
 } 
$command = "C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\i386\statview.exe"
$siteServer = "SCCMSiteSvr.contoso.com"
$startDate = Get-Date -Format "yyyyMMddHH:mmm.000" -Date $date
$Computers = Get-Content $path
foreach($compName in $Computers)
{
    $commandArgs = "/SMS:Server=\\$siteServer\ /SMS:SYSTEM=$compName /SMS:COMPONENT=Task Sequence Engine /SMS:COMPONENT=Task Sequence Action /SMS:SEVERITY=ERROR /SMS:SEVERITY=WARNING /SMS:SEVERITY=INFORMATION /SMSSTARTTIME=$startDate"
    & "$command" $commandArgs
} 

in-line script execution time-out…

Had this recently on a machine we were upgrading to Win 10 1909. Initially it looked as though there was an issue detecting the application being installed correctly but on closer inspection, the AppDiscovery log file revealed that the same timeout issue was happening on several applications. Googling about there were quite a few posts on how later versions on ConfigMgr now incorporated a client property to change the script timeout setting but this sadly appeared not to be the case. Other posts suggested a script that could be run at server level to fix this. Not really the short-term fix I needed to sort my issue as it would doubtless take weeks to get the change through at work.

Then I found what I needed – a client-side script which I have now lost the source to, so really sorry if this came from you. I’m happy to set the record straight and link as needed. In any case, I do have the script itself, see below. This wil set the timeout to 1200 seconds (from the 60s default). This fixed my issue. I would imagine this could be added to the start of a task sequence if required. Note it’s a VBScript…old skool.

On Error Resume Next
strQuery = "SELECT * FROM CCM_ConfigurationManagementClientConfig"
Set objWMIService = GetObject("winmgmts:\\" & "." & "\ROOT\ccm\Policy\Machine\ActualConfig")
Set colItems = objWMIService.ExecQuery(strQuery, "WQL")
For Each objItem in colItems
objItem.ScriptExecutionTimeOut=1200
objItem.put_()
Next

Set objWMIService = GetObject("winmgmts:\\" & "." & "\ROOT\ccm\Policy\Machine\ActualConfig")
Set colItems = objWMIService.ExecQuery(strQuery, "WQL")
For Each objItem in colItems
If 1200 = objItem.ScriptExecutionTimeOut Then
WScript.Echo "True"
Else
WScript.Echo "False"
End if
Next 

Timed out waiting for CcmExex service to be fully operational

The mis-spelling above is intentional BTW, this is how it appears in the SMSTSLOG.log file. Typically a task sequence will be ticking along then something will happen after which the above error is displayed, almost always when it is trying to install either a ConfigMgr package or a ConfigMgr application (ie not a command-line). This is because the client isn’t actually required to execute, for example, a Powershell command line, but it must be initiated if a package or application is called on.

Ultimately, in my experience, this always comes down to one issue – an inability to reach the Management Point. There maybe various reasons for this and one such reason is described here.

However in my case this wasn’t the problem. Following a task sequence upgrade to 1909, I found all our laptops failing with this same error. These laptops were all on the internal network (ie not connected via VPN/DA, etc). If I logged on locally, I found that while I was able to ping machines, I was unable to reach shares from other machines on the network. Something was very wrong with networking (and obviously why the build was failing).

Running an IPCONFIG /all revealed that the broken laptops were all trying to use the IP/HTTPS Tunnel Adapter Interface. This synthetic interface is typically used for Direct Access which these laptops were certainly not using at the time. On further investigation, if I removed the group policies the laptops inherited for the duration of the upgrade I was then able to complete the upgrade without issue.

THE SOLUTION

The group policies are causing the tunnel adaptor to become active albeit briefly (haven’t got to the bottom of why this happens BTW). Unfortunately the adaptor isn’t able to communicate with the MP as it should. Then I read an article about a bug found in the 1909/2004 OS’s. You must ensure this patch (Oct 2020 update) is applied to the installation media prior to upgrade. Essentially, the certificates were disappearing causing the communication problem with the Tunnel adaptors on the laptop models. Once the patch was added, all was well.

Configmgr client application stuck at 0% downloading

I’ve been meaning to do a quick blog about this issue for some time now especially as I have witnessed this incredibly frustrating problem at two separate clients during roll-outs, particularly OS deployments that also require updated applications, etc. A Google search will reveal many different ‘fixes’ for this issue, most common of which tends to involve re-installing the ConfigMgr client. Indeed this is an approach I took first time round and usually seemed to work but it isn’t really a fix as such.

In the latest instalment, this approach just didn’t work at all so I needed to find what else was causing the issue. If I left the offending application to time out – this might take several hours btw – I could usually restart it and it would go ahead and download. However this was still unacceptable.

SOLUTION

Turns out the answer, with hindsight, was the same in both instances – too many policies. Essentially in both circumstances, the machines experiencing the issue had a lot of applications and/or task sequences deployed to them. Task sequences in particular usually have many steps and this seems to flood the client causing it to display this ‘stuck at 0%’ behaviour. Try removing the machine from all unnecessary collections, leave for an hour or so for the machine to expunge any of the old deployments and try again.

This still feels like a Microsoft issue to me but until it’s addressed this is the workaround.

OneDrive needs your attention. Onedrive can’t sync now please try again later.

I recently had this while uploading thousands of photographs to my ODfB account. Essentially, you’ll set it syncing (perhaps overnight) and then come to it in the morning and you’re presented with the error message, “OneDrive can’t sync now, please try again later”.

I tried resetting the app (onedrive.exe /reset), re-starting, reinstalling, nothing worked. Turns out, there is a limit to how much data you can upload per day.

The Solution

The setting you want lives in the ClientPolicy.ini :

For ‘standard’ (personal) OneDrive, go to: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\settings\Personal\ClientPolicy.ini.

For OneDrive For Business (ODfB) OneDrive, go to: C:\Users\<username>\AppData\Local\Microsoft\OneDrive\settings\Business1\ClientPolicy.ini.

Please note, depending on your OneDrive setup and number of accounts, the Personal/Business folder name may change.

Open the ini file in notepad and change MaxClientMBTransferredPerDay from its current value to something higher. I found that I needed to change this value to 50000000 in my case. It appears that simply setting it to ‘0’ doesn’t work for infinite, either.

One other observation: occasionally, I noticed OneDrive would appear to change this value back to what it was and fail again. Just repeat the procedure above and it will carry on.

Hope this helps.

Unable to license Office 365 ProPlus

I don’t know quite how widespread this issue is but it’s something I have had some trouble with on and off since I updated my OS to Server 2019 last year. That said, I’m not saying this is an issue limited to this OS; indeed I have seen it on other OS’s too.

The issue is this : Word will ask you to sign in and after entering your email address, it will freeze for 5 minutes before returning you to the (unlicensed) state you were previously in. Similar with Outlook – you enter your email address and the white password box appears but appear blank and freezes for 5 mins before returning you to the previous (unlicensed) state.

There are a number of things that you might try (including full uninstall/reinstall in desperate cases) but I’ll show you a couple of things you should try before doing this (or calling Microsoft, as they will ask you to do this too, more likely than not).

First – Remove previous license information

  1. Open C:\Program Files\Microsoft Office\Office16
  2. From a cmd prompt, type cscript .\OSPP.VBS /dstatus
  3. This will give you a list of previous license keys used. Remove all these using cscript ospp.vbs /unpkey:<5 digit code>

Second – (if the above doesn’t work) Disable Modern Authentication.

Open up regedit and navigate to the following key:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity

Add a new DWORD value called EnableADAL with a value of 0.

Open up Outlook and it should now present you with a password window you can actually use. Word/Excel etc should open up as expected.

For a little more info on Modern Authentication in Office 365 see here.

Phased deployments not deploying

AKA…

Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: objectID
at Microsoft.ConfigurationManager.PhasedDeployment.Application.Deploy(IDatabaseOperation databaseOperation, List`1 phases, String phasedDeploymentID, String objectID)
at Microsoft.ConfigurationManager.PhasedDeployment.PODRuleEngine.EvaluatePhasedDeployments(SqlConnection connection)

I was testing a phased deployment the other day and couldn’t get it to work for the life of me. Although the phased deployment appeared under the Phased Deployments tab for the Office 365 application I was targeting, a corresponding deployment didn’t appear for the phase 1 collection under the Deployments tab.

I took a look at the SMS_PhasedDeployments.log on the site server and all I could see was the error message above. I would also see it repeat about every 2 minutes as below.

It kept mentioning there were two phased deployments it was trying to evaluate, but there were no other phased deployments set. There is a well-known bug when a task sequence can get locked and the admin will typically go into the db and remove the offending ID locking the task sequence from the database. Well it turns out this is a similar issue with an equally similar solution.

SOLUTION:

  1. Go into the ConfigMgr (sorry, Endpoint Manager!) DB and find dbo.PhasedDeployment, right-click the table and click Select Top 1000 rows.
  2. Identify the offending Phased Deployment from the list and copy the PhasedDeploymentID.
  3. Click New Query from the toolbar and type:

DELETE FROM dbo.PhasedDeployment WHERE PhasedDeploymentID='<PhasedDeploymentID>'

I would be inclined to delete and recreate your original phased deployment (from the console!) to be sure of a clean deployment but technically you be good from here on.

Add SSL Certificates For SCCM

Arguably there are newer and more fancy ways to do this in recent iterations of SCCM. If you wish to set up a standard internet facing SCCM environment or just an SSL secured environment this is the old skool way.

CREATE SCCM CERTIFICATES

  1. Open CA | Right-Click Cert Templates > Manage
  2. Right-Click Web Server template > Duplicate template
  3. Open new duplicate template :
    a Request Handling tab: Check ‘Allow private key to be exported’
    b General tab : Change name to “ConfigMgr IIS Cert”, validity 5 years
    c Subject name : default (‘supply in the request’ should be checked)
    d Security tab : remove the ‘Enroll’ permission from Domain Admins and Enterprise Admins, add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK
  4. Open CA | Right-Click Cert Templates > Manage
  5. Right-Click Workstation Authentication template > Duplicate template
  6. Open new duplicate template :
    a Compatibility tab: keep defaults (ensure Windows Server 2003)
    b General tab : Change name to “ConfigMgr DP Cert”, validity 5 years
    c Security tab : Add your SCCM_Site_Servers group and add Enroll and read permission to this group | Click OK. Remove ‘Enroll’ for Enterprise Admins. On Request HandlingĀ tab, selectĀ Allow private key to be exported
  7. Right-Click Workstation Authentication template > Duplicate template
  8. Open new duplicate template :
    a Compatibility tab: keep defaults (ensure Windows Server 2003)
    b General tab : Change name to “ConfigMgr Client Cert”, validity 5 years
    c Security tab : Click ‘Domain Computers’ group and add AutoEnroll and read permission to this group (don’t uncheck ‘enroll’) | Click OK
  9. Open CA | Right-Click Cert Templates > New > Certificate Template to issue
  10. Select the three new certs from the ‘Enable Certificate Templates’ box. | Click OK
  11. Open the GPMC, open default domain policy (or wherever you have your PKI policy)
    a Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
    b Open up ‘Certificate Services Client – Auto-Enrollment’. Change ‘Configuration Model’ to ‘Enabled’
    c Check ‘Renew expired certsā€¦’ and ‘Update certificates that use cert templates’

ADD CERTS TO SCCM

  1. On the DP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
  2. Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr DP Cert’ and click ENROLL > Finish
  3. While still in the certs MMC, Right-click the DP cert you have just imported > All Tasks > Export > Next. Select Yes, export private key
  4. Keep defaults on Personal Information Exchange ā€“ PKCS #12 (.PFX) and click next.
  5. Enter a password > Next > Save the file as C:\Temp\SCCM_DP_Cert. Click finish
  6. On the MP open the certificate MMC > Computer > Personal > Certificates | Right-click folder > All Tasks > Request New Certificate
  7. Next > Next | On ‘Request Certificates’ page check ‘ConfigMgr IIS Cert’ and click ‘moe information is neededā€¦’ link
  8. Under Subject Name, select ‘Common Name’ and add the name of the server, eg SCCMMP01 > Add
    9.Under Alternative Name, select DNS and add the FQDN of the server > Add
  9. Under the GENERAL tab, add the name of the server as the friendly name
  10. Under the Cert Authority tab, select your CA if it’s not already selected. Select Enroll > Finish.
  11. On the MP (internet facing if there is one) open IIS > Default Web Site > Bindingsā€¦ | Edit HTTPS
  12. Select the new SSL certificate. If you don’t see HTTPS, click add and create it.
  13. Repeat the above on any other MPs
  14. From the SCCM console go to Admin\Overview\Site Configuration\Sites | Properties > Client Computer Communication. Add the Root CA Certificate you created earlier.
  15. FINALLY!!!! Go to Admin\Overview\Distribution Points | Properties and add the certificate and password you created on the DP in point #5. Rinse and repeat for all your DPs.
    Just select YES if you get a message about it being a copy of one used on another DP.
  16. To add certs for the SUP/WSUS see https://www.petervanderwoude.nl/post/how-to-configure-a-software-update-point-to-use-ssl-for-communicating-with-wsus/