Active Directory settings from Groups menu don't save if Group is empty
-
I am running trunk 6150, I created groups which will all have independent OU’s in AD so that when they join the domain will fall under the correct OU.
Problem is when the group does not contain a computer yet the settings don’t save for the AD part of the group.
When you add a computer in then it when you populate the AD fields it’ll keep it, but if the group becomes empty then the AD information also get wiped.Would it be possible to also have the possibility to add other information in AD, like computer description or other?
Thanks!
-
That’s correct.
Groups are a way to alter hosts en-mass. It does not store individual settings with the exception of the general items.
-
This is by design, a group cannot dynamically update hosts as they are added. Instead when you add machines you must then go in and apply those settings to the group and it will update each host. A group is more of a place holder that you can change settings to multiple computers at once, unfortunately you cannot have a group that auto applies settings each time you add it to the group. This is why the AD settings appear to not be saved in the group, when you set them it changes each host currently in the group, there is no place in the DB that it stores the information for the group as a whole.
-
Additionally, from a development and programming perspective - it greatly simplifies what would otherwise be extremely complex and CPU/Network burdensome. I really like how FOG treats groups, and I plan to use this model with any software I write in the future.
-
Ok, is there maybe another way you guys think for me to achieve OU AD joining?
See I’m trying to replace an MDT server which has a script to choose an OU to add a computer to at the beginning of the process, people here are used to do this so I was thinking if I put Groups with different OU’s in each one, I could then have the same feature…
Additionaly, when FOG does the invetory it asks for the main user of the pc and 2 tags. Would it be possible to use that information?
i.e.; main user name could populate AD’s computer object description of one of those 2 tags? Ideally we could have a choice to fill the AD computer description filled with either the user name or the service tag…I get it that if the group is empty the settings cannot reside anywhere in a database but it’s still funny to think they use default settings… If I create a group something should be stored there…
I am a bit scared that some people would see this as a way to reject FOG. See, we have about 20 OU’s for departments, I won’t be able to fill those up for a few months (most likely) unless I join a vm to it maybe just to have the settings applied because even though when it does the inventory and it asks me if I want the computer to join a group, assign software installations and join the domain, since the first part which is joining an OU isn’t working well the computername remains random and not joined to the domain, FOG service installation failed and additional software install not happening.
So I get it, but i’m pretty sure this is not waht you guys want users to experience… unless I really didn’t understand the meaning of the groups…
Is there maybe a possibility for me to create dummies, at least one in every group?
Maybe that should be done automatically? Like a stealth dummy…What’s your stance on this?
-
@FlowLive Well you have touched on requests I’ve asked for… for a while.
- Being able to access host specific data during imaging.
https://forums.fogproject.org/topic/6463/expose-fog-host-and-image-properties-to-post-install-scripts - Having persistent groups.
https://forums.fogproject.org/topic/6902/in-search-of-fog-1-3-persistent-groups
https://forums.fogproject.org/topic/6637/fog-2-0-persistent-group-settings
They are on the developers request list, but not very high right now.
I think I almost have a hack for the persistent groups part figured out. I have a need to attach clients to specific OU based on their location. So I have a location for each site. I also have a requirement at each site to place workstations into different OUs based on the function of that device at the sites. So it is rather complex on how I need my OU structure setup. The static OU structure that FOG has is find for a single site, but falls down in a bit more complex environment.
I do have a path forward for me if I can’t get the persistent groups worked out.
Post image deployment FOG can be setup to run a bash script. With that bash script I determine the location of the deployed device based on its IP address and subnet. Also based on the image deployed I can tell the function of the device, so I can predict the OU where the device will reside. Through a little calculation I can build the proper OU for the device on the fly post image deployment. And with a short (but complex) sed function I can set the correct OU in the unattend.xml file on the target computer. When the computer goes through the oobe process upon setup it connects it self to the proper OU in AD. The only drawback I found is that if the device already exists in AD but in a different OU, winsetup will not move the device only reactivate its account. So I created a small vbs program (on the target that gets run during the first login process) that moves the computer to the proper OU. There is a lot of moving parts, but it does work well.
My point is there are ways to get done what needs to be if the system doesn’t support it out of the box. Do you have a unique key that you can use to calculate the proper OU for your target machines?
- Being able to access host specific data during imaging.
-
@george1421 said:
Do you have a unique key that you can use to calculate the proper OU for your target machines?No it’s not that complicated, I just have a bunch of OU’s and put pc’s in through the groups instead of manually.
Like I said my main concern is that I am pretty sure this could be a turn off for a few people NOT to move from MDT to deploy images.
I am not critisizing at all, I love FOG and understand the effort put into this, just that sometimes a dev point of view vs a user point of view might not coincide with reality. One hand it’s coded this way by design but on the other hand feats like those could be what makes someone driven away from a product.I’m no coder, I wish I was sometimes to understand better the dev reality and also could contribute in some ways.
Ideally I guess I should have some setup complete command that would have the user input the OU to put it in and would also add whatever information to AD computer’s description line, like it is setup now with MDT. I am pretty sure I will just create a few dummies to have at least 1 pc in every group so that there a no surprises when one finally add pc’s to an empty group.Has there been a request to populate additionnal fields in AD? Like the 2 tags we’re asked for when inventoring, any plan to have that info pass around in a set place in AD? Might as well use that info. Is there a place to create requests?
-
Not to go too deep into this, but you have 20 OUs, and you are onboarding a new PC. How do you know where to put it?
You have to remember that FOG itself does not add the computer to AD, its actually the fog service that runs on the client that does this task. As in my request, if we could make the host fields available to the postinstall linux scripts we could then update the unattend.xml file to use vbscript on the fist admin login to update the fields in AD as you wish.
I have a the hack for group persistence working on my dev box. If it proves stable, then you could use that function to set new hosts to match a host template you would setup ahead of time.
-
@george1421
The OU’s are actually departments, so we add them to those OU’s.If you find your way is stable let me know, I’m always in for some tweaks!
-
@FlowLive So far the persistent groups as I laid out in the kb and link previously is working in my environment. A formal solution (authored by the devs) would be better. But if there is no plan to support persistent groups in fog 1.3 (as of today) then this solution should work for you too. You will just need to create your host consistent templates and then setup your host groups as outlined in the KB.
