Wiki login
-
Not sure if this is the right forum, but the wiki redirected me to the forums to request a login for the wiki. I’d like to make a few clarifications, for example firewall exceptions has:
[FONT=monospace][COLOR=#000000]netsh advfirewall firewall add rule name=“Fog Client” dir=in action=allow program=“C:\Program Files\FOG\FOGService.exe”[/COLOR][/FONT]
But for 64-bit that should be “Program Files (x86)” I believe. So copy/paste of that stuff needs some care.
Let me know if you need any other information fro me.
-
-
As I still haven’t received wiki access, here one more important bit of information: for the Active Directory integration the user name MUST NOT include the domain name. That information is sometimes mentioned, but [URL=‘http://www.fogproject.org/wiki/index.php/Managing_FOG#Active_Directory_Integration’]this section still says you may have to include it[/URL] that. That won’t work.
-
In development versions it Will work with or without it
-
[quote=“Tom Elliott, post: 43938, member: 7271”]In development versions it Will work with or without it[/quote]
Isn’t that going to be confusing? The issue is with this: [url]http://192.168.0.1/fog/service/hostname.php?mac=aa:bb:cc:dd:ee:ff[/url].
If you enter a fully qualified domain, and no domain name in the user name, wouldn’t it return:
[CODE]#ADUser=www.example.org\Administrator[/CODE]
? I tested that against 1.2.0 and that’s clearly rejected by Windows.
I’ve modified the wiki to point out you need an unqualified domain name, and no domain name in the user section, then things will work.
-
Again, that’s based on environment. I’ve heard others need to use the qualified domain name and some need not to use it. In development version it detects the presence of a @ or \ and if it’s not present it will add the domain to the user otherwise it will leave it alone.
-
For my environment, I do not use the FQDN for our domain name. For username, it’s just a regular old username, No slashes.
I’ve asked Tom about this before, and as he’s said here, I really think it’s an environment thing. Probably DNS related, actually. Our DNS service in my particular building needs some tuning but I just haven’t gotten around to it.
-
[quote=“Wayne Workman, post: 43979, member: 28155”]I’ve asked Tom about this before, and as he’s said here, I really think it’s an environment thing. Probably DNS related, actually.[/quote]
Not really. It’s related to the NetJoinDomain call that’s made in HostNameChanger, and that determines 100% of what goes into these fields: we simply have to follow the Microsoft specs to get things to work.
-
Im using the developers version currently SVN 3410. domain join had some issues we found when the default field for the OU to join was left blank. so i populated the field with the direct ldap path and it worked flawlessly. it had something to do with our AD enviroment and our 2012 servers. we have 5 AD/DC’s and 2 DHCP Servers redundantly configured. these are all on site in the same room connected with a 10gig backbone. upgrading to the new client was easy, getting the system to join the domain took some time to figure out. At this time it works like a champ.
