I am very new to DSC and looking to bootstrap Windows machines in my environment but cannot see how I can do that using DSC. I will be grateful if someone can help.
From what I have read so far is that DSC relies on computer name to run the configuration. In my scenario I have got a Freshly sys-prepped Windows image which has nothing but WIndows installed with updates on it and winrm enabled. I also know the administrator password.
I want to use DSC to add that machine to the domain and install some software. I don’t know the current name of the machine. I want to give it a new name and add it to the domain and then install the required software. How can I achieve using DSC.
If you’re talking about Push mode (the Start-DscConfiguration command), all you need is a “name” that allows you to connect to the computer. That can also be the IP address, which you should have.
The basic flow I used was to use PowerShell remoting to create a configuration during build time, and then retrieve those values in the midst of an SCCM/MDT Deployment.
You could do something similar using your MDT Exit Script to run a local piece of powershell code which would create a configuration, rename it to your computer name, and then execute the configuration.
DSC relies on the computer name only when you’re PUSHING the config to a node. When a node is configured to PULL its config, it does so using a configuration ID (a GUID) that you must configure in advance.
So a brand-new, “naked” machine will not be pulling its config.
DSC isn’t really designed to work from a freshly sys prepped machine. For example, SCVMM includes the ability to “inject” the DSC initial configuration file into a newly-deployed VM - so that’s one way a “fresh” machine gets pulled into the DSC infrastructure. I suppose it might be possible to include, in your master image, a DSC configuration that has the LCM pull (from a pull server) a “generic” configuration, which in turn could reconfigure the LCM to “pull” the machine’s “permanent” configuration. But that’ll get pretty complex.
Keep in mind that DSC’s functionality is currently tailored for server workloads, not clients, and it doesn’t have any specific domain dependencies. There’s kind of an assumption that you’ve got automation tools already in place for server OSD, and that getting the DSC config onto the machine will be part of that automation.
Don, do you have more detail on this? Right now I rely on scripts running on a Hyper-V host and want to move this to SCVMM soon.
[blockquote]SCVMM includes the ability to “inject” the DSC initial configuration file into a newly-deployed VM [/blockquote]
From my experience so far I’ve been using just enough script to get the machine running to the point where I can let DSC take over. My scenario is creating servers for dev/test, so the idea is to create them quickly and consistently, then throw them away when the dev/test task is done. The things I do BEFORE DSC include:
[ul]
[li]Create a new VHD[/li]
[li]Copy an unattend.xml file into the VHD[/li]
[li]Install KB2883200[/li]
[li]Create and start a new VM using the new VHD[/li]
[li]Install the certificate used by DSC to decrypt credentials[/li]
[li]Configure the LCM[/li]
[li]Start DSC[/li]
[/ul]
I managed to bootstrap the windows image on both vmware and hyper-V using some fancy scripts to prep the image pre-sysprep. Part of the issue for me is that sys-prep destroys any certificate keys. so I had to store the .pfx and password to decrypt it in the image. otherwse I would be stuck with plan text password in the .MOF.
The process I’m using is this
Install Root CA from comany PKI so machine trusts pull server
install KB2883200
copy over PFX, RunDSC.CMD scrip, SetupDSC.ps1 script, unattent.xml into the image
sysprep
on VMWARE during the template deploy process i have it run RUNDSC.com with a GUID as an argument (that creates a text file). then reboot. ON hyper-v I have DSC inject a text file with the GUID into the VHDX (using a customized version of the resource from Microsoft where test-targetresorce returns true if the vhdx is in use)
The unattent.xml has a a run synchronous that starts RunDSC.CMD. (power shell is not available at this point on the build process)
RunDSC.cmd
if run with a GUID argument creates the txt file with the GUID
create a scedualed task to run itself on boot.
The system reboots, either due to unattent.xml or the vmware template task sequence
on the next run RunDSC.cmd detects the GUID file and runs starts SetupDSC.ps1
SEtupDSC.ps1
installs the certificate used for passwords.
formats any Raw disks.
creates the meta.mof using the GUID from the file
uses Set-DscLocalConfigurationManager to start DSC
We have our branch servers as hyper-v servers using this method we run a script off a USB that starts DSC on the physical machine and it builds the VM’s, come back in 30 minutes and have the two vm’s fully build and ready. VM’s on VMware are a few more mouse clicks but still a big time saver.
Don’t know if it’s kosher to bump such an old thread but Don, could we possibly get an update on this process?
I’m really trying to work towards your cattle vs pets mantra and I feel like this a vital step in it. The goal is to stand-up a completely configured VM as fast as possible without touching it (right?)
I’m currently trying to perfect this but know a couple things have changed since the things in this post were written, making this workflow a little bit dated. Also, this link is mentioned in Don’s DSC book, but I know for example that the DSCRestartBootTask scheduled task doesn’t exist anymore.
Is the preferred method still using unattended.xml and RunDSC.cmd files? I really couldn’t find any current information on the whole injection process…
Currently I use a custom function that creates a new VM from a SCVMM template whose VHDX has been sys-prepped - with the DSC credential cert stored in \LocalMachine\My, and a MetaConfig.mof file injected so that it pulls a config to join the node to the domain (I plan to further expand this configuration past just domain join, once I get this issue sorted out). The pull and subsequent config work perfectly, but only when my credentials are stored in plain-text, which is not ideal…
So my issue is just like David’s above where sys-prep destroys the private key for my credential encryption (although the cert is still shown in certmgr). Although, different from David I’m trying to avoid having my cert password (or any password for that matter) stored in a file in plain-text at any point, which seems to be happening in David’s SetupDSC.ps1 (I could be wrong about this).
Any tips on this whole server bootstrapping process?
And if DSC isn’t the right tool for what I’m trying to do, what is?
Again sorry for bumping such an old thread, I’ll make a new one if necessary, but I’ve been banging my head against the wall for a couple weeks with this issue.
I’m bootstrapping DSC using nothing but the unattend.xml.
Instead of creating a scheduled task to create the LCM config, I create the metaconfig.mof file during the specialize fase in the unattend file.
Check it out: http://dscrocks.azurewebsites.net/
Credential encryption is handled by a resource which downloads and install a pfx certificate.
Works like a charm, I use only WDS. No need to inject files in VHDs or sysprepping machines.
Would it not be possible to setup your node’s LCM to pull with a registration key and a configuration name? This assumes a few things, one being you’ve conquered deploying DSC with partial configurations.