Unclear how to drop devices into specific OUs on Domain Join
-
Hello,
I am on the IT team for a school district with 4 buildings. We’re working on getting FOG set up in our environment. Currently, I’m stuck on the following:
What I want to accomplish:
- Computers in specific FOG groups ( e.g. Middle School Teachers) to be placed in the appropriate OU (e.g. OU=MS Teachers Laptops,OU=Teachers,OU=Computers,OU=MS,DC=EXAMPLE,DC=local) during imaging.
What’s currently happening:
- If I perform a full host registration, even if I associate the computer to the group I want, it seems to just apply default domain settings or not join domain at all.
- If I perform a quick host registration, then manually set the computer to the group I want via the web interface, it doesn’t seem to join the computer to domain.
At best, if I go through full host reggy, and tell it to specify domain, it will join our domain but pop it in our Default Computers OU, ignoring group settings.
Is there a “Good And Proper” way to accomplish my goal here?
-
@joshua_mchugh I’m not sure if there is a good and proper way to do it but there maybe some way to go about it.
If you use an unattend.xml file that file and windows can place the computer into the proper OU. The idea is to use a post install script programmed in bash to dynamically update the unattend.xml script at deployment time. You can’t use fog group per se to do this since they are really “set groups” where the groupings are only used to bulk update parameters. But if your OU can’t be calculated you can use the user fields in the host record, and or the image name could be determined in the post install script.
I’ve got some examples of how to calculate a host name and OU based on the target IP address of the computer being imaged. This isn’t your solution but shows you what is possible in a post install script in the links below.
https://forums.fogproject.org/post/69726
https://forums.fogproject.org/post/69725In one section of the links above it shows how to post a question at deploy time that could change how the OU path is calculated before the unattend.xml script is updated. The last tip is to use a post install script to leave bread crumbs behind so that the setupcomplete.cmd or the first run section of the unattend.xml file can find and integrate into an OU path. At one deployment we had to first set the target system’s OU to a clean OU used specifically for imaging because the OU GPOs would break OOBE/WinSetup. Once the system was fully configured we use the unattend.xml auto login and first run section to call a VBS script to read the bread crumb (info saved in a text file) to then finally move the computer to the correct OU.
None of these are proper, but as they say if all you have is a hammer, everything looks like a nail.