In part I and part II of this series I showed how to install the WDS role, MDT 2013 and ADK for Windows 8.1. I showed the process to import the OS images and the necessary drivers for our deployment. Now it’s time to bring MDT to life. Let’s start with part III of this series. User for deployment share access During the deployment process Windows PE needs access to the deployment share.

After installing the required software, we need to configure MDT 2013. You need: Windows Server 2008 R2 ISO VMware Tools for Windows ISO or a Server with VMware Tools installed The deployment share First of all we have to create a deployment share. This file share is used to access the software, drivers etc. during the deployment phase. Just start the Deployment Workbench, that can be found in the start menu.

Usually you can install virtual servers on four different ways: Installation from scratch image-based installations (e.g. Clonezilla) VMware templates and template customization specifications automated deployment Except VMware templates you can use every technique to deploy physical and virtual servers. I would like to show you how you can install windows-based VMs with Microsofts Deployment Toolkit 2013 (MDT 2013). There are three articles in this series. The first article describes what you need for MDT 2013 and how you install WDS.

What are the requirements of MDT 2013? The requirements are manageable. To recreate my small lab environment, you need two VMs or physical servers and a evaluation copy of Windows 2008 R2. MDT 2013 and ADK for Windows 8.1 can be downloaded for free on microsoft.com. I used two Windows 2008 R2 VMs for my setup. One VM as a Domain Controller with DHCP and the second VM for MDT 2013 and WDS.

During the installation of a really small vSphere environment, I used the 60 days instand-on license. This allows me to use some fancy vSphere Enterprise Plus feature during the installation. Specifically I use host profiles to configure the ESXi hosts. At the end of the installation process I removed the host profiles and installed the Essentials Plus license. The enviroment consisted of two HP ProLiant DL360 Gen8, a dual-fabric SAN with a HP MSA 2040, two Brocade 300 FC switches, some more stuff and a vSphere Essentials Plus license.

While playing around in my lab, I wanted to enable VMware Fault Tolerance (FT) for a VM. In the absence of physical HW I use a nested enviroment, which is running on a HP ProLiant DL160 G6 (2x Intel Xeon E5520, 32G RAM, a RAID 0 with 4 SATA drives). FT isn’t available in nested enviroments, because HW virtualization features are required. This screenshot was taken from the web client.

During a vSphere 5.0 > 5.5 upgrade I got this message: The SSL certificate for this product is expired. See Knowledge Base article kb.vmware.com/kb/1009092 The customer hasn’t installed CA-signed certificats, so the expired certificates are the out-of-the-box self-signed certificates. The certificates are valid for two (VirtualCenter 2.5) respectively 10 years (since vCenter 4.x), depending on the Version. The only way to continue the installation is to renew the certificates. After renewing the certificates, you can simply continue the setup due the fact, that the vCenter service is stopped at this point of the setup and it loads the new certificates during startup.

Scott Lowes “Reducing the Friction” posts inspired me to write a bit about a part of my job. A significant part of my work is the on-site installation of newly purchased equipment. That’s one thing my customers really like. I’m not only the pre-sales guy that is doing designs and workshops, but I am also the guy who installed the things which he has thought up. This prevents finger pointing if something isn’t working as expected.

In November 2013 I published a PowerShell script on blazilla.de that creates a backup of your SANsymphony-V config by using the DataCore SANsymphony-V PowerShell cmdlets. I would like to thank Marcel, Michael and Frank for their feedback and comments to improve the script. The password is stored in the securestring.txt that needs to be stored in the same directory as the script. Kudos to Marcel, who has the part of the script contributed, that stores the password in an encrypted file.

Over the last months I wrote different PowerCLI One-liners who I want to share. Nothing fancy and one or two are ugly. But they worked for me. :) Changing the multipathing policy for all hosts and datastores in a cluster Get-Cluster PROD | Get-VMhost | Get-scsiLun -CanonicalName “naa.60030*”| Set-ScsiLun -MultipathPolicy "roundrobin" Get a list of all VMs in a cluster and the datastore in which the VMs resides Get-Cluster | Get-VM | select name, @{N="Datastore";E={Get-Datastore -VM $_}} | sort name