Computers slow to a crawl after domain join
-
Server
- FOG Version: 1.4.4
- OS: Ubuntu 16.04LTS
Client
- Service Version: n/a
- OS: Windows 10 Enterprise 1607 &1703
Description
I am having an issue which only appears after an imaged computer is added to the domain. I can take and apply images perfectly fine. I am not using the fog service at all.
Once the imaged computer goes through OOBE and logs in, I manually add it to our domain, reboot and then the problems start happening. The windows 10 settings app will take 2-5 minutes to load, pressing the start button and starting to type for a search is also delayed. Even things as simple as right clicking the desktop and going to display settings is delayed by several minutes.
I have tried running checkdisk, repairing the windows install, etc, but nothing seems to work.
The only solution I have found is to either wipe the computer and install without using an image, or removing the computer from the domain.
Any help on this matter would be greatly appreciated!
-
Was the original (master) image ever connected to the domain?
Before you captured the image, did you run sysprep and have sysprep power off the computer?
This doesn’t sound like a FOG problem, but more of a windows problem. I can tell you I use fog to image win10 systems quite a bit. I haven’t run across this issue before. But I use MDT to build my golden image, capture and deploy with FOG. I let the unattend.xml file connect the target computer to AD, so I too don’t use the fog service much for imaging.
-
This post is deleted! -
The master image was never on domain, fresh install with nothing except windows updates and chrome.
Yes, ran sysprep /generalize /oobe /shutdown then took image immediately after the shutdown.
I would agree that this doesn’t sound like a FOG issue, but the issue will only appear if the computer joining the domain was imaged. For example, if, instead of taking an image, I just joined the master image machine to the domain, these issues do not appear.
-
@espynn So if you disconnect the computer from the domain, does it return to normal?
If you never connect the computer to the domain does it remain normal?
If while on the domain and running slow, what happens if you disconnect the computer from the network?
I’ve failing to see a connection between imaging, connecting to the domain and the slowness you are seeing. There has to be something going on here that is unseen now.
-
@george1421
Yes, removing from the domain and the issues go awayYes, without ever connecting to domain, issues do not happen (computers fresh installed from ISO of windows, and added to domain also do not experience issues)
Disconnecting from the network seems to have no effect
I’m failing too, that’s why I’m here!
This issue is replicated across different windows install versions, different unattend.xml’s, different computer models and makes, different images and even different computers the images were taken from. I’m scratching my head here, the ONLY connection between computers that have the issue is that they were imaged from fog. We are going to be testing SCCM in the coming months, so I might be able to test if a different imaging solution entirely, resolves the issue.
…There isn’t a GPO template for “make imaged computers run slowly” is there? [/s]
-
@espynn said in Computers slow to a crawl after domain join:
There isn’t a GPO template for “make imaged computers run slowly"
This is my thought too. Instead of turbo mode, you found snail mode.
If you have the capabilities, move that computer to an OU where you are blocking all GPO policies. So the computer will be connected to AD, but no gpo policies will be applied.
It could be something silly like if you had AV installed in the golden image and when connected to AD its trying to do something and timing out causing the delay. AV is typically installed post imaging because (depending on the AV solution) a guid is created which needs to be system unique.
It would be also interesting to know if the slowness is observed when disconnected from the network.
SCCM is a good solution if you can support the infrastructure requirements. It is more than just imaging so not really in the same class as fog.
-
@george1421 No AV and network disconnect does not seem to matter. I will try another OU with GPO blocked though. Our GPO is a bit of a black hole and no one really knows what’s going on down there to be honest
Thanks for your help, if anyone stumbles into this thread, the issue is not resolved but I will report back with findings .
-
@espynn said in Computers slow to a crawl after domain join:
The windows 10 settings app will take 2-5 minutes to load, pressing the start button and starting to type for a search is also delayed. Even things as simple as right clicking the desktop and going to display settings is delayed by several minutes.
These statements would cause me to check out task manager to see what program is Taking the resources. That will lead you to the answer after a couple Google searches.
-
@wayne-workman I agree, first thing I did. No tasks were using more than normal baseline amounts of resources.
-
@espynn did you Check the network tab in task manager?
-
@wayne-workman yes. As I said below, network connected or not didn’t matter, and normal baseline resources.
-
@espynn are these desktops or laptops? any map drives getting mounted automatically? Any printers installed automatically?
-
@wayne-workman either or, no and no.
-
@espynn any software being installed automatically?
-
@wayne-workman nope, just (seemingly) normal default GPO policy. Not even moved from default computers OU.
-
@espynn is roaming profiles turned on for users? Is folder redirection being used?
-
@wayne-workman neither, and again, normal resource activity, including network activity.
-
@espynn what’s dns primary and secondary set to? Do these match the domain controller addresses?
Get the domain controller addresses by using nslookup. Example, my domain is fogproject.org, I’d do
nslookup fogproject.organd all DC addresses will be returned. -
@wayne-workman I’ll check after the weekend, I would suspect we would have wider issues across the entire domain if this were mixed up. But we have had some large scale network changes recently.
Anything else to check?
