Jump to content


Damien

Compiling a Gold master to use in VMWare VDI envirenment

Recommended Posts

Hi,

 

I am using SCCM 2012 R2 CU3 and MDT to compile an image for use in my VDIs. This is what I do.

 

1) Run the SCCM build task sequence to build a VM with all the Apps and updates (works great).

  1. Delete the c:\windows\smscfg.ini file from the client
  2. Run CCMDELCERT on the client (*)

4) Seal the snap shot.

 

After provisioning the image to a pool, whai i am seeing is VMs in that pool get the same GUID which was in the gold master image.

 

This is what I found in the ClientIDManagerStartup log file on one of the effected clients( please see attached log). the client generating a ned GUID and try to register with the server but the server reply to the client back with the gold master GUID.

 

can someone please help us of shed some light? Thanks.

 

ClientIDManagerStartup.log

Share this post


Link to post
Share on other sites

In our environment, these are the steps that I do:

 

* Run TS

 

* When the TS is done, login as the local admin

 

* Open administrative cmd prompt, do a NET STOP CCMEXEC to stop this service

 

* Open the certificate console for the local computer, delete the two certs displayed in the SMS node (MMC > Certificates > Local Computer)

 

* Delete the smscfg.ini from C:\windows\

 

* Lastly, sysprep the VM. Since we use Windows 8.1 for our VDI farm, I use the cmd sysprep.exe /generalize /oobe /shutdown /mode:vm

 

It's too bad there is no complete automation of this process in SCCM. Hopefully the next version has some support for creating a master VDI disk.

 

-Robert

Share this post


Link to post
Share on other sites

Creating a master VM for VDI should always be done with the machine off the domain (i.e. WORKSTATION context). In our organization we use Microsoft RDS and have the broker create the pool of VM's, which during the task, joins each machine created to the domain.

 

In my previous response to your question I left out one other detail. I created a startup script for the VM's in the pool to do a NET STOP CCMEXEC, pause for about 30 seconds, then NET START CCMEXEC. I found by doing this it will prevent the VM's from reusing the GUID from the master VM. All 60 or so VM's that I manage for RDS have unique GUID's.

Share this post


Link to post
Share on other sites

What i have done is , I run SCCM build task sequence to build the Gold master, which puts the gold master in the domain. then I do these steps:

 

Open administrative cmd prompt, do a NET STOP CCMEXEC to stop this service

* Open the certificate console for the local computer, delete the two certs displayed in the SMS node (MMC > Certificates > Local Computer)

* Delete the smscfg.ini from C:\windows\

 

* Lastly, sysprep the VM with an unattained answer file.

 

Sys prep puts the PC into a workgroup. then I take the snap shot for VDI.

 

once the pool is recompose with this GM, the first VM to come online from the pool gets a unique GUID (this is different to the GM GUID) and shows up in the SCCM console. once the second vm comes online, that VM takes the same GUID as the first VM and the first VM disappear from the SCCM console and only the second VM shows up in the console. once all the VMs comes online in that pool. only the last VM to come online appears in the SCCM console because they all have the same GUID.

 

not sure what i am doing wrong.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.