Windows 10 Enterprise Computer Name Problems (SCCM 2012 R2 SP1)

[pembertj]

I'm having a strange issue, starting to mess around with building a Windows 10 Enterprise image for our campus and I seem to be having a problem with the task sequence properly reading in the computername that I give it.

Windows PE phase:

1. Prompt for OSDComputername using VB Script (same thing we have done with Win7/8.1 with no issues)

2. Use powershell to check variables: OSDComputername shows correct name and _SMSTSMachinename shows correct name. Checking $env:computername in PE shows MINIWINPC or something (which is normal)

3. After Apply Network Settings C:\windows\panther\unattend\unattend.xml shows the correct name

 

Windows phase:

1. Machine gets name WIN-XXXXXXX

2. Use powershell to check variables: OSDComputername shows correct name and _SMSTSMachinename shows correct name. Checking $env:computername in PE shows WIN-XXXXXX or later in the task sequence DESKTOP-XXXXXX

3. Machine joins domain and at end of task sequence has name of DESKTOP-XXXXXXX but seems to sometimes join domain under name WIN-XXXXXXX and end with DESKTOP-XXXXXX and cannot log into the machine (security database relationship error with domain controller)

 

Has anyone ran into anything like this in Win10 or Win7/8.1 and found a solution? Out of probably 20 imaging attempts and fiddling with various settings I have only got it to get the correct name once...

 

Thanks

 

~Tom

[jones948]

I do the same thing (.HTA at the start of the TS to supply a computer name), and am seeing the same problem with the machine name. The computer is named DESKTOP-xxxxx at the end of the deployment.

 

What's your source image for the OS? I'm using a captured reference image with Office 2013. When I switch the image to the install.wim from the Enterprise .iso, the problem goes away.

 

Odd thing is, it was working for me, but then I recaptured my reference image to include .NET 3.5, as one of our apps requires it.

[pembertj]

Captured image, I haven't tried with just the install.wim right from the DVD - not really a feasible option in the long term...

[jones948]

Check the CCMExec.log on one of your DESKTOP-xxxx machines. If you scroll back to the beginning of the log, do you see time stamps from your original capture? (I am)

 

I'm wondering if the client isn't getting initialized properly during the capture and so we're deploying an image with remnants of the original client install.

 

Edit: Nevermind - just mounted the .wim of one of my older images that works fine and it has the logs from the original capture.

[letster]

Hi pembertj

 

I am seeing the same problem.

I made my .wim file on a SCCM 2012 R2 SP1 CU1 - without ADK 10 installed.

It's a regular Build and capture from the DVD media from Microsoft partner website (build 10240 x64)

 

My logfiles state the everything is all fine and dandy - but it gets ignored - just like your are seeing.

A scripted install though works just fine - but i would love it getting a build and capture to function too

 

Edit 1: Also had a look into c:\windows\panther\unatten\unattend.xml - to see if the computername is correct, which it is.

Edit 2: I took a closer look into c:\windows\debug\netsetup.log - to see what computername it thinks it has, and this shows me "Win-xxxxxx" - and i can see that it is successfully joined to the domain, afterwards i look on the domain, and love and behold, it is - BUT the computername of the machine is not "Win-xxxxx" it's "Desktop-xxx".

It's a bit strange.

 

Kind Regards

Letster

[pembertj]

I have been using Win8.1 ADk as well, but from what I've read on here and a couple of other blog posts it seems like you might actually need Win10 ADK - I am going to attempt the process again today with Win10 ADK installed on my site.

 

~tom

[jones948]

I'm using the Win 10 ADK, so that does not appear to be the source of the problem. I'm also on 2012 R2 SP1 CU1 (have been on CU1 prior to beginning my Windows 10 testing).

 

I also ran into this problem when I first started testing SCCM and my build and captures were failing because of the "updates with multiple reboots" issue. The build would fail and end up at the login screen (rather than the Windows setup page) get captured like that, and subsequent deployments with that capture would get named MININT-xxxxx.

 

Even though I had the new "retry" option turned on for Software Updates, I disabled all software updates in my build and capture for Windows 10 and still have this problem.

[pembertj]

We just went to R2 SP1 CU1 as well. Whats strange as well is I've had it fail 20x on VMs but the first time I tried it on a physical machine it works fine...

[jones948]

Ah, interesting. What VM software are you using?

 

I got excited and put 10 on my workstation and had to put the beta of VirtualBox 5 to do my builds and testing. Trying to recall if it ever worked correctly under the VirtualBox beta.

[pembertj]

The ones I've been testing it on are Hyper-V VMs that have worked fine for win7/8.1 captures that we do. I'll test more on vmware vms and some physical machines and see if it is something with the hyper-v VMs...

 

~Tom

 

//edit: strange it worked on a vmware vm with no problems. I am going to attempt on another model Dell machine here (or two). I'm curious if it is just related to Hyper-V VMs for some reason...