Tag: OSD

Specific computer model not joining the domain.

I recently had an issue with a specific computer model not joining the domain. The Task Sequence had not been updated for a while, and we had not done any significant changes to the environment. With other computers working flawlessly, we had issues with a HP EliteDesk 800 G3 DM 35W not joining the domain for some unclear reason. This was the start of an interesting discovery.

The issue began when this EliteDesk 800 G3 wouldn’t join the domain. Usually when a Task Sequence finishes, the computer reboots and you see a login screen, stating the domain and asking for credentials, as shown in this picture.

Usual image after a successful Task Sequence

This time the EliteDesk didn’t show any domain, just asking for local Administrator credentials. My first guess was network drivers, so I started by updating the boot image with fresh network drivers for EliteDesk 800 G3. Even with up-to-date drivers the computer wouldn’t join the domain. I started going through the SMSTSLog, BDD.log, checked if something had failed during the Task Sequence. No errors were found. But still, the computer would not join the domain.

I started digging deeper and went through the “panther\UnattendGC\setupact.log” and the “debug\NetSetup.log”. It was here where I started to find some interesting issues.

We have an environment built around an OU structure based on location and computer type (desktop, laptop or virtual machine). The ComputerTypeOU property is saved in to a variable used in the Task Sequence. What OU the computer is added to is decided in the CustomSettings.ini-file. 

In both the setupact.log and NetSetup.log I found out that no value was saved in the “%ComputerTypeOU%”-variable.

NetSetup.Log of EliteDesk 800 G3 DM 35W

My initial thought was that the log prints the string without any value connected to the variable, but after going through the same logs on a newly installed computer, that had no issues joining the domain, I quickly found out that I was wrong. The variable should definitely contain the value generated by the CustomSettings.ini file.

NetSetup.Log of EliteBook Folio 9480m

As shown in the first image, the EliteDesk 800 G3 did for some reason not receive any value to this variable. I started going through logs once more, trying to find out why this computer was unable to fetch the required value.

Since we unfortunately do not have an OU named “%ComputerTypeOU%” in the domain, and the Join Domain-account was unable to create one, the computer did not join the domain because of the account used in our Task Sequence having insufficient rights.

But why this variable was missing its value was the main question. I started going through logs again, and this time I had something to look for instead of searching for the unknown. The BDD.log gave me a good overview of all the client properties. I compared a domain joined client with the EliteDesk 800 G3. Here I stumbled upon an interesting fact. The EliteDesk did not report as a laptop, a desktop nor a server, as shown below.

BDD.Log of a EliteDesk 800 G3 DM 35W

BDD.Log of a EliteBook Folio 9480m

 

Since the EliteDesk 800 G3 did not report any of the values needed for our structure, the solution was to add Model to the Priority list and associate EliteDesk 800 G3 with the “ComputerTypeOU”-property set to workstations.

After adding the Model property to the CustomSettings.ini file, the EliteDesk 800 G3 joined the domain flawlessly after running a Task Sequence.

This might not be the best solution to this matter, but it sure is a practicable fix. If anyone has a preferable solution, feel free to email me at johan.nilsson@xenit.se



Use PowerShell & Windows Update to force drivers to be downloaded from the Internet in a Task Sequence

Working with client driver packages for me is related to a never-ending story. Drivers are frequently being updated and results in manually handling updates of Driver Packages in Configuration Manager. But since some computer manufacturers are releasing updates through Windows Update, so we thought; What if you can use a Task Sequence to force Windows Update to look for updates and drivers over the Internet instead of using manually handled Driver Packages? So I decided to try with a Surface Book.

With help from the PowerShell Module PSWindowsUpdate, created by Michal Gajda (downloaded from TechNet), and with a post from Waingrositblog, I had all the necessary bits forcing a Surface Book to download drivers from Windows Update, over the Internet, while running a Task Sequence. I started by modifying the steps, created by Waingrositblog, in the Task Sequence steps a bit. I found having one step running a PowerShell script instead of three steps, two of which was running cmd lines, more suitable.

This image illustrates the Task Sequence step.

I added the update step just after applying Windows- and Network Settings, where we usually apply driver packages.

The RPS (Run PowerShell) – Microsoft Update step is running the following script:

To verify the success of the script I went through the WindowsUpdateLog.Log and found that during the Task Sequence, a lot of drivers were installed. Here I would like to use PCI drivers as an example. As shown in the image below, the WindowsUpdateLog successfully downloaded and applied the drivers.

This is the WindowsUpdateLog.Log generated after successfully running the Update Drivers sequence.

I also tried the running the Task Sequence without the Windows Update / Driver script and found out the device had conflicts with the PCI drivers. These drivers is just used as an example in this process, there are several conflicts and other drivers missing as shown in the image below.

This image illustrates conflicts with, among others, the PCI drivers after not running the Update Drivers sequence.

This image illustrates when the drivers are applied.

As shown in these images, the Install Driver step running in the Task Sequence finds the correct and necessary drivers. After a Task Sequence successfully has gone through no exclamation marks are found in the Device Manager.

Some computer manufacturers are using Windows Update as a secondary source for updates, and because of this some drivers can be out of date. This is a reason why the Surface is a great example of using Windows Update for drivers since Microsoft release their updates, up to date.

If you have any questions, opinions or improvements, feel free to email me at Johan.Nilsson@Xenit.se