What I wish I had known when I started developing Lability DevTest Lab Environments

Wed, 31 Jan 2018 12:33:16 +0000

At Black Marble we have been migrating our DevTest labs to from on-premises TFS Lab Management to a mixture of on-premise and Azure hosted Lability defined Labs as discussed by Rik Hepworth on his blog. I have only been tangentially involved in this effort until recently, consuming the labs but not creating the definitions.

So this post is one of those I do where I don’t want to forget things I learnt the hard way, or to put it another way asking Rik or Chris after watching a 2 hour environment deploy fail for the Xth time.

You can’t log tool much. The log files are your friends, both the DSC ones and any generated by tools triggered by DSC. This is because most of the configuration process is done during boots so there is no UI to watch.
The DSC log is initially created in working folder the .MOF file is in on the target VM; but after a reboot (e.g. after joining a domain) the next and subsequent DSC log files are created in C:WindowsSystem32ConfigurationConfigurationStatus
Make sure you specify the full path for any bespoke logging you do, relative paths make it too easy to lose the log file
Stupid typos get you every time, many will be spotted when the MOF file is generated, but too many such as ones in command lines or arguments are only spotted when you deploy an environment. Also too many of these don’t actually cause error messages, they just mean nothing happens. So if you expect a script/tool to be run and it doesn’t check the log and the definition for mismatches in names.
If you are using the Package DSC Resource to install an EXE or MSI couple of gotcha’s
For MSIs the ProductName parameter must exactly match the one in the MSI definition, and this must match the GUID ProductCode. Both of these can be found using the Orca tool

Package MongoDb {

PsDscRunAsCredential = $DomainCredentialsAtDomain

DependsOn = '\[Package\]VCRedist'

Ensure = 'Present'

Arguments = "/qn /l\*v c:bootstrapMongoDBInstall.log INSTALLLOCATION=\`"C:Program FilesMongoDBServer3.6\`""

Name = "MongoDB 3.6.2 2008R2Plus SSL (64 bit)"

Path = "c:bootstrapmongodb-win32-x86\_64-2008plus-ssl-3.6.2-signed.msi"

ProductId = "88B5F0D8-0692-4D86-8FF4-FB3CDBC6B40F"

ReturnCode = 0

}


```*   For EXEs the ProductName does not appear to be as critical, but you still need the Product ID. You can get this with PowerShell on a machine that already has the EXE installed

Get-WmiObject Win32_Product | Format-Table IdentifyingNumber, Name, Version


*   I had network issues, they could mostly be put does to incorrect [Network Address Translation](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/setup-nat-network). In my case this should have been setup when Lability was initially configured, the commands ran OK creating a virtual switch and NetNat, but I ended up with a Windows failback network address of 169.x.x.x when I should have had an address of 192.168.x.x on my virtual switch. So if in doubt check the settings on your virtual switch, in the Windows ‘Networking and Share Center’ before you start doubting your environment definitions.

Hope these pointers help others, as well as myself, next time Lability definitions are written

DSC on But it works on my PC!

What I wish I had known when I started developing Lability DevTest Lab Environments