I'm seeing some issues when using an OU (and child OUs) as a requirement for application deployment during OSD.

The target machine logs the application as "not required" during the Task Sequence, I'm guessing because SCCM hasn't got the OU information for the machine, yet. Is there any way I can trigger population of this data in ConfigMgr during OSD to facilitate this requirement specification.

I have a 'workaround' where I read the OU from ADDS however this won't work for IBCM clients - so I end up either having a working TS and breaking IBCM deployment of the applications, or vice versa.

Thanks,

SCCM gets the OU information from the registry and that is populated when the machine recieves group policy after imaging and domain join. You can try a gpupdate /force before the install application step

• Proposed as answer by Jason SandysMVP Thursday, June 20, 2013 12:32 AM

Thanks, I will give this a go and come back to you.

Any luck or work around? I am seeing the same issue.

Thanks.

Quick update...my logs looked like the ones in the link below and trying to separate out the apps to see if that helps. I have also recreated the apps and deployments in SCCM.

http://www.windows-noob.com/forums/index.php?/topic/5894-osd-install-application-limit-of-1-to-9

• Edited by Sulabh Upadhyaya Tuesday, July 16, 2013 7:18 PM update

You can try a gpupdate /force before the install application step

Isn't group policy processing disabled when a task sequence runs?

This is my understanding as well Torsten.  to the OP, could you use the Requirements of the deployment type to make this determination and just set it to run for all devices during OSD?  Just thinking out loud..

This is my understanding as well Torsten.  to the OP, could you use the Requirements of the deployment type to make this determination and just set it to run for all devices during OSD?  Just thinking out loud..

Tried various other ways, including a script that ran as a requirement to determine the OU by querying AD, this worked during OSD but, unsurprisingly, broke the Internet Based Client Management deployments of this application.

So what I ended up doing with this was building a script which runs during the TS and sets a Task Sequence variable dependant upon the contents of OSDMachineOU. Therefore I no longer need any OU requirement on the deployment type.

Thanks for your help on this.

Microsoft has confirmed that OU-Based application installation during OSD with that requirement is not working as per design.

Reason, like already mentioned, is that theres is no Policy/AD evaluation within a running TS.

Also, the OU-Requirement does not query the AD, but a registry value on the client, which is not representing the value of the Machine-Account in the AD during the TS.

I'm 'stuck' here as well...

My Office 2013 application has multiple deployment types (MUIs) with requirements based on OUs.

These are being ignored during OSD...

Is the only way around this, to amend my requirements on the application? I was going to add a reg key, but then realised that my Requirements can't have an 'Or' statement... i.e. This OU or this reg key... so if I added the reg key as a requirement, everything outside of OSD would break.

Would an AD site requirement on the application be better?

Could you create a custom Global Condition to accommodate the requirements?

I'd still need the ability to apply the 'or' condition...

i.e. OU as the current rollout works OR Reg Key for OSD... which I don;t think I could accomplish!?

I don't have the ability at the moment to look for sure but off my head I would think you could create a Global Condition for the registry key, then create another global condition that is an Expression and add OU or your custom reg condition?

Sorry to resurrect such an old post. Any idea as to what registry key it queries? I'm having this same problem and wonder if I can just set this key during deployment.

Hi,

Thats the Key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Distinguished-Name

You may edit this key during deployment and set it to the OU the machine currently belongs to. Just query the AD via any script technology you prefer to get the the correct OU and paste it to the registry.

Regards

• Edited by McAllstar 14 hours 39 minutes ago