Monthly Archives: September 2014

Deploying to unknown computers, populating OSDComputerName with PowerShell…

Imagine yourself with the following requirements when deploying Windows clients:

  • Computer objects are pre-staged prior to deployment
  • The naming convention is the computer’s asset tag with additional characters (in this particular example, it is CI<asset tag>)

The solution I was looking for was having the OSDComputerName variable populated with the naming convention. It would allow me not to care anymore if I was deploying to known or unknown computers (from a Configuration Manager). Having the objects pre-staged allowed not to care anymore for any OU related configuration or assignment.

I knew that it’s possible to have the OSDComputerName variable populated with information by using scripts. In the past it was done by .vbs scripts. But today we have PowerShell which can be used in a Windows PE environment if the boot image has the Windows PowerShell module loaded. So I started looking.

I quickly got to Nickolaj Andersen’s blog (again J) and I found exactly what I was looking for at the following blog post:

I’d like to thank Nickolaj for this little gem and all the credits go to him.

Fortunately, in my case I don’t make difference between a desktop or a laptop. Someone in the comments created a simplified script which would do the trick for me. I created a .ps1 file which contains the following cmdlets:

$SerialNumber = (Get-WmiObject -Class Win32_BIOS | Select-Object SerialNumber).SerialNumber

$OSDComputerName = “CI” + $SerialNumber

$TSEnv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$TSEnv.Value(“OSDComputerName”) = “$OSDComputerName”

After following the instructions displayed in Nickolaj’s post, I was able to successfully populate the OSDComputerName variable which meets the naming convention. Knowing the computer objects are pre-staged I’m able to deploy a Task Sequence to the ‘unknown computers’ without doing anything extra, great for migration purposes (especially when migrating to a pristine Active Directory forest). So no manual OSDComputerName prompt required.

So if the naming convention contains the asset tag, then you can try this out yourself. In a test environment first, that is…



Minimum required permissions to join a computer to the domain during OSD

Recently I was required to deliver the minimum required permissions to allow a computer to join the domain during Operating System Deployment. The challenge in this scenario was that each computer object is pre-staged in Active Directory prior to deployment. Here are a few but not all reasons why each computer object is pre-staged (let’s assume this is achieved by a PowerShell script):

  • A list of all computers exist, however the list contains only names (no MAC addresses or GUIDs)
  • Operating System Deployment needs to be simplified by not pointing to any Organizational Unit in the answer file
  • For each user a computer will be configured as a Primary Device, this is most likely used for file server related configurations

I guess I was lucky that at most projects in the past, the administrators told me which account to use since they already configured the required delegation for domain join. However, it was the first time that computer objects are pre-staged prior to deployment and I had to deliver the required permissions myself. Initially, I received the following error message:

“The join operation was not successful. This could be because an existing computer account having the name xxxx was previously created using a different set of credentials. Use a different computer name or contact your administrator to remove any stale conflicting raccount. The error was: Access is denied.”

After some digging I found the following blog post that helped me getting on track again:

After reading this post, I needed the following scenario:

2. Allowing a security principal to join and re-join a computer to a domain

The second scenario; allowing a principal to also re-join a computer to a domain requires some additional permissions. This is useful if you want to have a service account that can manage all computer accounts, also existing ones. System Center Configuration Manager for example requires these permissions.

According to the article the following permissions are required:

  • Reset Password
  • Read and write Account Restrictions
  • Validated write to DNS host name
  • Validated write to service principal name

In order to reproduce the behavior, I set up a small lab environment with a Domain Controller, a System Center 2012 R2 Configuration manager primary site server and two client machines. I did the following before deploying the machines:

  • Pre-stage the two computer accounts
  • Delegated the permissions to the account used for to join computers to the domain

The first client was joined correctly, after that I did the same with the second client and that one joined correctly as well. This means I was able to reproduce expected behavior. I consider that a result.

I’d like to thank Morgan for providing a detailed blog post which helped me achieve this goal. It comes back to having the right permissions to achieve the goal.

Feel free to try it out yourself, don’t forget to use a test environment before putting this in production…

UPDATE: the required permissions are also documented in the following KB article: This article applies to Windows Server 2012 (R2) as well.



A small reminder (and note to self) when working with DELL Driver CABs for enterprise deployment

As many people already know, DELL provides a very comprehensive set of driver packs that can be used with MDT and especially ConfigMgr. Personally, DELL’s approach works so well I would almost jump on a couch and scream ‘I LOVE IT’ for a few times. You can compare it with a well-known actor we know best for doing this in a talk show and is also known as a Scientology zealot 😉

But I said almost…

Not only are separate packs available for a single model, family packs are available as well which makes managing drivers a lot easier.

You can find the packs at the following locations:



At one my projects, I initially decided to create a single Driver Package for each family driver (or separate ones when required) which means that each package both contains the x86 and x64 drivers. Unfortunately, some models loaded the wrong driver. In my case, an x64 driver was loaded during a Windows 8.1 x86 deployment. This was not the behavior I was looking for.

After figuring out the issue, I decided to cut the packs in half and put the x86 and x64 drivers in separate Driver Packages. It’s a little bit more administrative effort, that particular effort denies me the time to jump the couch.

Let’s hope DELL’s competition can deliver a similar method which I haven’t seen so far…



Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen