Issue with User accounts Optiplex 7050
-
I have been experiencing a problem that has me baffled. After the latest Windows 10 patch I created a new image to be used with the new Dell Optiplex 7050 machines my dept is receiving. At the first everything was fine. I then began to get emails complaining that the machines were “slow” or that the programs were not working right. Sure enough. There is something wrong. I have tried pulling a new image but I just get the same results. After deploying the image I can use the machine fine as default or admin. The problems only begin to manifest when a user account is logged in. With the admin account logged in I can lets say do something as simple as enter the display settings, when logged as user opening those same setting would take at 10-30 minutes.
-
More often than not, I’ve found when a system is logged in using AD credentials, a slowness is usually due to GPO from the Domain Server. I’ve heard of this from at least one other person. It appears to be specific to the domain join itself.
https://forums.fogproject.org/topic/10683/computers-slow-to-a-crawl-after-domain-join
-
Biggest question I have, are you sysprepping the system?
-
@tom-elliott Yes we sysprep. The problem happens even if we do not domain.
-
@weaponode said in Issue with User accounts Optiplex 1050:
The problem happens even if we do not domain.
You mean login with local user accounts?
-
@sebastian-roth Yes.
-
@weaponode Can you remove the network cable and see if things work better, I know this sounds stupid, but please give it a shot?
-
Also, you may want to try turning off “Fast Start Up”. See if this is interacting in some way.
-
Some more useful/potentially helpful information:
https://forums.fogproject.org/topic/6748/help-with-win10-sysprep/20
-
@tom-elliott I incorrectly said 1050 in my original post. These new machines are actually 7050. We are currently attempting to implement some changes. UEFI one of the new variables. Also problem started at Windows 10 version 17.03.
-
@weaponode Ultimately, I don’t think the “model” of the system actually matters here. Rather the content of the image itself. While I’m sure it’s as it’s applied to the 7050, I would imagine this same problem would occur on any machine given the same image. Can you verify and test?
-
@tom-elliott I am relatively sure the problem is an unattend file. Have been successful with the image so long as I leave that file out during sysprep.
-
@weaponode There are ways to debug a failed unattend.xml file install. Its not easy but can be done. There are log files created when oobe runs, if something in the unattend.xml file causes oobe to stop that will be logged in these files. Getting to these files is a bit of a trick, but FOG can help us there too.
First before I get going here, make sure your unattend.xml file in only in c:\windows\panther directory and not in the sysprep directory.
actually now that I think about it, I had a similar discussion a few days ago about the same topic: https://forums.fogproject.org/topic/10861/error-when-capturing-image/16
The idea is you can pxe boot into FOG debug console, connect to the windows “C:” drive and the vi linux command prompt view the contents of these error logs. It may be just as easy to pop the hard drive out of the failed computer and add it as a second hard drive on another computer and then view the log files that way. But if OOBE stops, it should be logged in one of the error log files. It will tell you what went wrong.
-
@weaponode Do you still have that issue?
