Hostname Changer AD Issues
-
That makes sense! I was thinking along the lines of a corruption or similar with this specific issue.
I can check with our higher ups to see if we could create a local AD server for testing purposes to see if we would be able to work with this server on narrowing down the issues that are presenting themselves. Let me get back to you on this point and let you know if this is possible.
Thanks!
Lambo
-
I just wanted to update you Sebastian.
This Wednesday / Thursday I will be working with the AD team to view logs during the imaging processes. They are most likely going to request that I have access to set up a temporary AD Server / get access to their Test AD servers.
I am hoping to have an update for you after testing this week.
Please let me know if you need anything else.
Do you also have a link to the Fog recommended image process so i can ensure it is not an issue with our image as well? Our Windows version is Win 10 Enterprise 20H2.
Thanks!
Lambo
-
@lambo Sounds good. Keeping my fingers crossed that you will find out more soon.
Don’t think we have an official document on the imaging process. Just a few things that I have in mind:
- Disable secure boot
- Set disk controller to AHCI mode instead of RAID mode
- Disable bitlocker (
manage-bde -off c:) - Un-join from domain
- Disable fast boot in Windows 10 and do a clean shutdown
@george1421 @Tom-Elliott Some essential point I am missing?
-
Hi Sebastian,
I hope all is well with you!
Sorry for the delay.
Ok so we were able to produce the AD issue with the AD team.
Unfortunately, we didn’t see much happening in terms of event logs.
There were three separate failures that occurred, but not necessarily related to joining the domain in my experience. I could certainly be mistake though.
-
Audit Failure - Kerberos Authentication Service - 4786
-
Audit Failure - Directory Service Access - 4662
-
Audit Failure - Credential Validation - 4776
None of these failures utilized our image account for Fog / Hostname Changer, so I don’t see them as being a smoking gun unfortunately.
The AD Team was planning a migration for our AD server to Windows Server 2019, so they will be completing this ahead of schedule for us. This migration will take place this week, so we are hopeful that it could assist with resolving the issues that we are seeing.
If that does not work, the AD team will allow us to utilize a test AD server for troubleshooting this issue. We should then be able to fix up and test any settings we think are important.
Do you also know if it is possible to ‘lock’ the domain controller to a specific domain controller in Fog? This would be helpful so we could lock Fog in to utilizing our local domain controller instead of possibly utilizing another in the network.
Again, sorry for the delay, and thank you so much. I really appreciate your assistance!
Thanks!
Lambo
-
-
@lambo said in Hostname Changer AD Issues:
Do you also know if it is possible to ‘lock’ the domain controller to a specific domain controller in Fog? This would be helpful so we could lock Fog in to utilizing our local domain controller instead of possibly utilizing another in the network.
Do you have serveral AD controllers and want to force the client to use a specific one? That’s not something I can answer. From what I know about Windows AD I would guess the answer is No. But that’s definitely beyond my skills.
My thinking was you would setup a single AD testing server using a complete new domain for testing, not part of the existing domain in any way. Not sure if that’s possibly in your environment.
-
Hi Sebastian,
No worries at all, i just figured i would ask, as there are multiple domain controllers in our organization and i was hoping there would be a way to point fog to utilize the local DC. No worries though at all!
After testing with the Server 2019 DC in production, it seems that some of the issues presented have been resolved in some regard.
Here is what we found:
If a computer AD account already exists, it seems we can reimage with no issues now. we tested around 15 images and they all worked successfully. We can also reimage a computer where the AD account has been ‘reset’ instead of deleted. These tests were successful as well.
However, if we delete the computer AD account or image a new PC and have the option to add the computer to the domain, the issue we were previously experiencing exposes itself. The computer will allow AD accounts to log in, but trying to deploy software shows a trust relationship issue as well as having the computer nowhere to be found in Active Directory.
What would you like to see done here? I am about out of ideas on our end unfortunately, other than standing up a test domain and seeing if the issue persists there and if so, trying to narrow down where the problem is. I think we should be able to set this up and we can continue deeper testing there.
Thanks!
Lambo
-
@lambo Just wondering if you are still looking into that issue or got it solved at some point?