Has anyone gotten the SCCM client working in a Layered Image?

[Jamie OBrien]

Looking for a procedure, official or unofficial, from anyone who has had success with this.

 

Thanks!

[Steve Turnbull1709156601]

We’ve put our sccm client in the platform layer.  I had problems getting it to populate all its settings in the app layer it was just blank config.  Platform layer seems to have the highest priority so basically here’s how we got it working.

 

create platform layer or update existing one as we also have the vda in the platform layer

join platform layer to domain

install sccm client

reboot

check sccm client has correct config

remove platform layer from domain

reboot

login and shutdown for finalise 

[Jamie OBrien]

One last comment - use a domain-joined Platform Layer, but be advised that you'll need to decide how to manage BITS. The Optimization tool (in whichever layer you run it) disables BITS by design but can be toggled accordingly.

[Steve Turnbull1709156601]

ah the old duplicate guid issue.  yes the sccm client is not very good with provisioned machines.  it will work for a while and then the duplicate guids come back.  we had a ticket open with ms and they recognised it as a common issue with cloned machines and all the troubleshooting steps around stripping out guid before sealing didn't really help because the sccm db will just replace it back anyway!!

 

the only 100% foolproof way we found to make it work was to exclude it from the template and installed it through a start up action once the machine was up and on the domain.  this way it always created unique guids but obviously adds overhead to the whole process.  now we don't bother with sccm on our provisioned machines and just patch the os layer monthly through a script, similarly for office. this has worked much better for us and no more sccm issues. 

[Sukhpreet Boparai]

Upgrade to ELM 1911 and follow the sealing process described above by dblack84032. this fixed it for us. Take a clone of the appliance before you do the upgrade as there is no downgrade option incase it breaks things. After the upgrade if you get any errors regarding ngen process during the finalizing. Use the script below i copied from www.jgspiers.com to update the ngen process manually. 

 

$NGENPaths = Get-ChildItem -Path C:\Windows\Microsoft.NET\ -Recurse ngen.exe | Select-Object -ExpandProperty Directory
foreach ($NGENPath in $NGENPaths) {
cd $NGENPath
.\ngen.exe update
 }

[Jamie OBrien]

Never mind, I think. A colleague of mine found this, and we are testing it out:

https://support.citrix.com/article/CTX226394

 

[Derek Black]

On 11/28/2017 at 5:46 PM, Jamie OBrien said:

Never mind, I think. A colleague of mine found this, and we are testing it out:

https://support.citrix.com/article/CTX226394

 

Has anyone verified that this is working with SCCM 2016?

When I use the Recipe in an app layer I get a blank config and when I try it in the platform layer I get duplicate GUIDs

 

Thanks in advance!

[Derek Black]

On 9/20/2019 at 5:11 PM, Steve Turnbull1709156601 said:

ah the old duplicate guid issue.  yes the sccm client is not very good with provisioned machines.  it will work for a while and then the duplicate guids come back.  we had a ticket open with ms and they recognised it as a common issue with cloned machines and all the troubleshooting steps around stripping out guid before sealing didn't really help because the sccm db will just replace it back anyway!!

 

the only 100% foolproof way we found to make it work was to exclude it from the template and installed it through a start up action once the machine was up and on the domain.  this way it always created unique guids but obviously adds overhead to the whole process.  now we don't bother with sccm on our provisioned machines and just patch the os layer monthly through a script, similarly for office. this has worked much better for us and no more sccm issues. 

 

Thank you for the response!  A start up task is a great idea, but to your point adds overhead.  Funny thing is they only thing they want SCCM for reporting.  We are patching the OS layer with windows update.

 

It was confusing because the 'generalization' of the image fore SCCM/SCOM is something I do for a large PVS farm (~1000) and never have problem.  Was really trying to put it in a regular App Layer but I couldn't get it to work.

[Derek Black]

Despite following the 'Recipe', I could not get SCCM to work in an Application layer no matter what I tried with PVS (blank config usually).

 

It seems like it has to be in the Platform Layer when using PVS as it is joined to the domain and Platform Layer has the highest precedence. (This was mentioned in a previous post)

 

I was able to get it to work properly by adding it to the Platform Layer which is joined to the domain and then clear the SCCM config before Shutdown and Finalize. 

1. Join Platform Layer to domain with the packaging VM in an OU that SCCM is monitoring (PVS would already be joined to the domain w/ VDA, PVS target, WEM, etc.)
2. Login with a Domain user w/ elevated privileges and install the SCCM client
3. Wait.....Wait until the packaging VM shows Green in the SCCM console
4. Restart
5. Login w/ local Administrator account
6. Delete Network Profile
7. Run 'Sealing Script' (generalize SCCM)
8. Run AppLayeringScript (JGSpiers)
9. Shutdown and Finalize

Here is the 'Sealing/Generalization' script I use that includes some additional tweaks including SCOM (I'm not the original author).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

     REM ** This section generalizees the SCCM client and removes the identity of SCCM Client **
     @ECHO Prepping SCCM Client Services for Imaging...     
     net stop ccmexec

     del %WINDIR%\smscfg.ini 
     Powershell -command "Remove-Item -Path HKLM:\Software\Microsoft\SystemCertificates\SMS\Certificates\* -Force" 
     wmic /namespace:\\root\ccm\invagt path inventoryActionStatus where InventoryActionID="{00000000-0000-0000-0000-000000000001}" DELETE /NOINTERACTIVE

 

     cscript c:\AutomatedDiskCleanup.vbs

 

     REM ** This section generalizees the SCOM client and removes the identity of SCOM Client **

     @ECHO Prepping SCOM Agent Services for Imaging...
     net stop healthService

     Powershell -command "Remove-Item -Path 'HKLM:\Software\Microsoft\SystemCertificates\Operations Manager\Certificates\*' -Force" 

 

     gpupdate /force

 

     net stop "Norskale Agent Host Service" /Y

     vietool.exe --generate C:\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

• Here is a link the AppLayerPrep https://www.jgspiers.com/citrix-app-layering-preparation-script/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I then updated the OS layer, edited the template and published the updated Image.  All 3 initial test machines worked as expected.  Then ran through the XenDesktop wizard in PVS and deployed additional machines (20 total), all reporting correctly in SCCM.  They all have been rebooted several times mimicking the patching process and normal routine reboots.  I am happy to report that so far I haven't seen duplicate GUIDs, duplicate entries in SCCM, the behavior is identical with other PVS images, and I now have more confidence this will work as expected. (Just a little hack lol)

 

[Derek Black]

I see that there is some newer documentation released April 2020 where it looks like they now recommend SCCM be in the Platform layer.  We had this working great with for a POC using procedure I documented last September Server OS (PVS, different Citrix farm). 

 

We are in the process of setting up a POC using AppLayering for our VDI workloads (MCS, different Citrix farm). 

 

Just curious of others experience with the new App Layering Recipe for SCCM?

 

Any other gotchas, tips or tricks that you may have stumbled across would be greatly appreciated.

Thanks in advance!