SCCM OSD Task Sequence Pre-stage Client

[rhughes]

Hello.

We currently have an OSD Task Sequence for deploying Windows 10 Enterprise 1709 to our client machines. This works quite well for existing PCs which are known to AD and SCCM. We have a mixed environment, where we have multiple departments which require their own set of applications. Again, this works well for existing machines.

The issue in which I'm being faced with at the moment, is when we introduce new clients to the environment. Due to the design of SCCM with AD System Discovery, new devices are not discovered as there is no DNS entry for those devices. I have done the following -

Pre-staged computer accounts on Active Directory.
Created computer objects within SCCM with the Name and MAC address of the new devices.
Added new objects to the OSD Device Collection for OSD.
The problem here is that some Device Collections which have Collection Variables attached, rely on Active Directory OU membership rules. As these machines haven't yet been discovered as such, they don't become members of these collections until the OSD process has finished the installation of the ConfigMgr Client has completed. Once that has completed, the machines then fall into the correct collections, but the Install Applications step within the Task Sequence doesn't complete as the collection variables haven't yet been evaluated.

I was wondering if anybody else here has experienced this and maybe have a solution/work around? Would there be any Powershell scripts which could be used to force a re-evaluation on collection variables prior to the Install Applications step?

Cheers,
Richard

[xerxes2985]

Richard,

If you've manually added the computer objects to an OSD Device Collection, there might be something wrong with one of your applications in you install application step. Have you checked to make sure each application is distributed to the DP?
 

22 hours ago, rhughes said:

The problem here is that some Device Collections which have Collection Variables attached, rely on Active Directory OU membership rules. As these machines haven't yet been discovered as such, they don't become members of these collections until the OSD process has finished the installation of the ConfigMgr Client has completed. Once that has completed, the machines then fall into the correct collections, but the Install Applications step within the Task Sequence doesn't complete as the collection variables haven't yet been evaluated.

This statement doesn't make sense. The applications you are deploying using the install application step shouldn't be reliant on which collections the computer objects are in, unless you're doing something like this (Separate Task Sequence to deploy applications to a specific collection): 

If you're deploying applications during OSD, you should have a step similar to this (Install application), that is not reliant upon which device collection the object is in.

Also, curious why are you pre-staging computer accounts in AD, is it so you don't have to manually move them to the appropriate OU afterwards?
 

Edited March 22, 2019 by xerxes2985
added context

[rhughes]

Hello,

Thank you for your response. I should probably have explained this a little better. We have Device Collections for each faculty, each collection has a collection variable "SA" (Special App), 01, 02, 03 and so on. Each variable represents the name of an Application on SCCM. These collections query their membership based on Active Directory OU... so any new machines which aren't known on the network, can't be discovered in those collections.

 

Cheers,
Richard

[xerxes2985]

Richard,

I just went through and pre-staged a computer in AD, and created a device collection with an OU query, and a collection variable with a few values of applications. I'm going to see if I run into the same issues with the membership not updating.

I believe I may have found a script that might do it, but I don't know if it can do it during OSD. https://gallery.technet.microsoft.com/scriptcenter/ConfigMgr-UpdateRefresh-68041cc7

I'm testing your process myself to see if I encounter the same issues.

[xerxes2985]

Here's my findings so far:

The script does work during OSD. I checked the console and did a refresh of the page during the script running and the hourglass icons appeared on the collections. My AD computer object is viable (no longer a placeholder) but in looking at the log file for the active directory discovery (adsysdis.log), it shows the following error:

GetIPAddr - Host not found resolving FQDN "Lib-TestDummy.domainname.edu".    SMS_AD_SYSTEM_DISCOVERY_AGENT    3/22/2019 3:40:01 PM    2172 (0x087C)
GetIPAddr - Retry with system name "LIB-TestDummy"...    SMS_AD_SYSTEM_DISCOVERY_AGENT    3/22/2019 3:40:01 PM    2172 (0x087C)
ERROR: GetIPAddr - GetAddrInfoW() for "LIB-TestDummy" failed with error code 11001.    SMS_AD_SYSTEM_DISCOVERY_AGENT    3/22/2019 3:40:04 PM    2172 (0x087C)
ERROR: Machine LIB-TestDummy is offline or invalid.    SMS_AD_SYSTEM_DISCOVERY_AGENT    3/22/2019 3:40:04 PM    2172 (0x087C)

You may have more success with that script, or not. One suggestion I might say try, is create a standalone application Task Sequence like this, and deploy the Task Sequence to your collection ("Academic...") as a required deployment. Image your systems, update your memberships manually (or fire off that PowerShell Script) after the systems are at the windows logon screen, and see if those collections reflect the new systems.

You could also do the same application TS below (or just as a step in your OSD TS), and when you are importing the computers into SCCM, go ahead and add them to a "Staging" collection for those specific applications.

Then, operate as normally to deploy applications to those dynamic collections.

 

 

[xerxes2985]

@rhughes, 

After trying to image and get the dynamic collection to update using the linked script, I was unsuccessful. The script does work, but the collection that "should" update still doesn't reflect the member, and in turn, causes failure to install the applications.

I'm not sure if anyone else may have success doing this with a collection, but I think your best bet is to create a staging collection with those members added manually rather than trying to do it dynamic. 

Sorry I could be of more assistance,

 

Jesse

[rhughes]

On 3/25/2019 at 3:46 PM, xerxes2985 said:

@rhughes, 

After trying to image and get the dynamic collection to update using the linked script, I was unsuccessful. The script does work, but the collection that "should" update still doesn't reflect the member, and in turn, causes failure to install the applications.

I'm not sure if anyone else may have success doing this with a collection, but I think your best bet is to create a staging collection with those members added manually rather than trying to do it dynamic. 

Sorry I could be of more assistance,

 

Jesse

Hi Jesse,

Thank you very much for your time and effort on this, it's really appreciated! In regards to a staging collection, I was wondering what your thoughts were on this? I'd like to find a solution which still allows me to hold one list of applications to install (collection variables), for each faculty. I'd rather not have two copies of the same list of software... I'm thinking of maybe creating a second task sequence which could run after OSD for "New" devices which performs the application installs...

Cheers,
Richard

[rhughes]

On 3/27/2019 at 2:35 PM, rhughes said:

Hi Jesse,

Thank you very much for your time and effort on this, it's really appreciated! In regards to a staging collection, I was wondering what your thoughts were on this? I'd like to find a solution which still allows me to hold one list of applications to install (collection variables), for each faculty. I'd rather not have two copies of the same list of software... I'm thinking of maybe creating a second task sequence which could run after OSD for "New" devices which performs the application installs...

Cheers,
Richard

Hello,

Thank you for your response on this. I couldn't find a practical solution to this problem, so we have chosen to make an adjustment to our naming convention to allow us to query based on hostname.

Cheers,
Richard