SOLVEDDistribution points fail to instal VCREDIST

[ronnydrak]

Hi,
After upgrading to SCCM 2207 are all our Site servers getting this error when trying to upgrade. In distmgrlog
"Failed to install vcredist on DP , ErrorCode - 8, Hresult - 0x0 SMS_DISTRIBUTION_MANAGER 2022-11-30 16:43:32 15144 (0x3B28)"
In Distribution Point configuration status we get error
Distribution Manager failed to install distribution point DP.
Possible cause: Distribution manger does not have sufficient rights to the computer
Solution: Verify that the site server computer account is an administrator on the distribution point computer.
If i would reinstall Windows everything works without having do anything.
The rights are assigned by group in AD so the server has group that inclues SCCM server account, service account for SCCM with DA.

Any suggestions? Having to reinstall 50+ site servers feels abit wierd.

[KyleASimpz]

I was going nuts on this issue. We use Cortex XDR. We ran into the same issue 6 months ago when i upgraded our MECM environment to 2207 but at that time all Windows 10 DP's are fine and the issue happened only on Windows server DP's and i had to use different account other than site server system account to install the DP. Once the DP is installed, i was able to switch it back to site server system account.
From past 2 weeks, this issue started happening again for Windows 10 and server DP's. I had to use another account to install DP role and for majority of the DP's it worked but some DP's it did not worked. What seems to work so far is me manually RDP into troubled DP's and add the account to administrator account that i was using for installing DP even though this account is already part of security group that has admin rights on all DPs.
I am still on 2207.@ronnydrakdid you guys opened a case with Palo for this issue.
这个问题是很奇怪和令人烦恼的交易。
Please share if any of you guys use Cortex and running into same issue like me.@kevinsteck @Djal @Mata101Alex

How long after did it take for the install to occur when you used another account?

[SCCM_etc]

The cycle on our system took about 25 minutes before it re-tried to update the deployment server. It only took a few minutes to complete the update after that. (on a single Deployment Server) Turns out we did not have to disable Cortex to delete the SID from the registry on the deployment servers. It depends the Cortex settings. Same thing with using a different service account. The cycle took about 20-25 minutes to retry the update, then only a few minutes per deployment server to complete.

[KyleASimpz]

The cycle on our system took about 25 minutes before it re-tried to update the deployment server. It only took a few minutes to complete the update after that. (on a single Deployment Server) Turns out we did not have to disable Cortex to delete the SID from the registry on the deployment servers. It depends the Cortex settings. Same thing with using a different service account. The cycle took about 20-25 minutes to retry the update, then only a few minutes per deployment server to complete.

The SID I need to delete is the logged-in user SID ?
The user I'm logged in the SID isn't blank.

[Brian]

The SID I need to delete is the logged-in user SID ?
The user I'm logged in the SID isn't blank.

Assuming the same scenario, and assuming you are using the System account of the Site Server to install the DP role, you would use that server's SID. You can also retrieve the computer object's SID through PowerShell using Get-ADComputer .

[propbuildervash]

Fantastic post guys.
We are having the exact same issue in our environment here which started Oct 20th. We have been fighting the same issue since then. We use a dedicated service account, I noticed that none of the DP's had a properly cached profile for that service account. As part of the effort to resolve the issue we have cached the account by logging into each DP as the dedicated service account, which created a dedicated profile on each box. I am waiting for the next release of SCCM to confirm that this is a good workaround Ideally we want to get XDR fixed so we can use the site server computer account if we decide to go back to that methodology for authentication. In the meantime we have also opened a case with Cortex regarding the issue as this post 100% correlates with the same symptoms and disabling Cortex prevented new blank profiles from being created in our environment too.

Cortex responded with the following:
Addressed Issues in Cortex XDR Agent 7.9.1:
https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/7.9/Cortex-XDR-Agent-Release-Notes/Addressed-Issues-in-Cortex-XDR-Agent-7.9.1
CPATR-19009
(Windows)
Fixed an issue where a Windows function registry key was created falsely, which led to the creation of empty user profiles, resulting in a compatibility issue with SCCM deployment.

Please upgrade the Cortex XDR agent to version 7.9.1 and let us know if the issue has been resolved.

Prior to October 18th we were running XDR 7.7.1.62043 with no problems and after seeing this post I found that we had upgraded XDR to 7.8.1.113.43 just a couple days prior to the SCCM upgrade in October when the problem started. We tried running XDR 7.9.0.20664 on the DP's and still have the issue. We will be upgrading the affected DP's to 7.9.1

Seriously, 100x thank you's, I've been fighting this for six months since only two updates have been out to troubleshoot since then, its nice to have some idea of the root cause.

[Kisage]

We opened a ticket with Microsoft and got a better answer: Cortex is causing the issue:
The variable SID for the primary site server is created as a blank profile under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList (psgetsid $ will get the variable SID. Without the $, you will not get the correct SID) The blank entry causes a WMI fault 8 so SCCM cannot update vcredist or IIS. (even if vcredist doesn't need to be updated)
Using a different service account may get around the issue but it may come back the next time you update CM. (on one server, we switched from the site server computer account to a service account to fix the issue before we updated SCCM. The update broke the new service account and we had to switch to a second service account)
Fix: Disable Cortex, delete the empty SID from the registry, wait for SCCM to complete the update, then re-enable Cortex.
Now we get to go back and clean things up so all 148 deployment servers are setup the same.

Have same scenario: Cortex XDR and DP installation fails. It started from CCM 2203/2207 belive. Not sure which Cortex version had at first tries.

Althou not sure if Cortex messed something at all, but wierd case that everybody that have this problem also have Cortex XDR in their infrastructure.

I can confirm and tested 2 workarounds:

1. using user or service account in SCCM that was previously not used. This method worked for me at first time in 11.2022,
2. Now I have used method with deleting empty SID of SiteServer in registry. Did not have to uninstall/disable Cortex at all. Simple SID entry delete and wait 20min to reinitialize DP installation - it succeed.
3. Did not tried above method with INvoke-Command which generally is creating profile for SiteServer ComputerAccount

We will se within a month how DP reinstall is going when I will update CCM to 2303 - update is pending.

[manju]

We opened a ticket with Microsoft and got a better answer: Cortex is causing the issue:
The variable SID for the primary site server is created as a blank profile under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList (psgetsid $ will get the variable SID. Without the $, you will not get the correct SID) The blank entry causes a WMI fault 8 so SCCM cannot update vcredist or IIS. (even if vcredist doesn't need to be updated)
Using a different service account may get around the issue but it may come back the next time you update CM. (on one server, we switched from the site server computer account to a service account to fix the issue before we updated SCCM. The update broke the new service account and we had to switch to a second service account)
Fix: Disable Cortex, delete the empty SID from the registry, wait for SCCM to complete the update, then re-enable Cortex.
Now we get to go back and clean things up so all 148 deployment servers are setup the same.

I tried with different SA account for site system installation .it works fine for some time and later same results .even that SID not exit on my primary server but that is present on DP ,do you want me to perform Disable cortex and delete SID from registry on impacted DP? please advice because i am facing same for 15 DP and i have single primary server with 2211 version .next month i am going to update server os 2019 then sccm upgrade for latest version .please advice for content distribution issue .its not package issue i tested with test package and its not reaching.

[ronnydrak]

We recently upgraded to 2303 and with XDR version 8.1.X it works again so Palo hotfix resolved this issue.