Archive for December, 2013

Install and Configure MDT 2013 (Part 2)

Monday, December 30th, 2013

In Part 1 of this series we walked through installing and configuring MDT 2013 for the first time. In this part I’ll show you how to globally automate the deployment. In terms of automation there are two types of automation, global automation settings that are applied by default to all machines and then those that are directed at individual machines. Firstly I will explain and demonstrate the global settings and then I will run through how to centrally apply individual settings to different makes and model of machines.

If we right click our deployment share we can access the configuration settings (properties) used for that share. Under the rules tab we can access two sets of settings, customesettings.ini (the settings you see in the pane) and Bootstrap.ini (the settings accessed by clicking the button).

 

These settings are held on the hard drive in the deployment share.

 

 

BootStrap.ini is used at boot time to provide basic configuration to the machine and allow it to connect to the deployment share. Because of this, changes to bootstrap.ini have to be placed inside the WinPE image by updating the deployment share whenever changes are made to bootstrap.ini.

Once the machine is booted customSettings.ini takes over and controls the rest of the deployment process typically automating entries in the MDT GUI to drive the deployment.

Let’s deal with bootstrap.ini first. If we click on the button above to open the ini file we see that, by default, its settings look like the below:

The [Settings] section is read in first and the process then follows the value in the priority field. Here it loads up the section [Default] which only has one value, the location of the deployment share to read data from. By default, all installations will use the same deployment share in this location.

We can add additional item to bootstrap.ini. The “typical” values we may want to add are:

UserID=Administrator

UserDomain=Example

UserPassword=Pa$$w0rd

KeyboardLocale=en-GB

SkipBDDWelcome=YES

 

I have highlighted the values to be changed in RED. A word of caution though, the username and password are held in plain text in the boot.ini file and, as you can see, this is held in the deployment share which, by default, provides all users with read access. If you were to use your domain administrator account in a production environment users could possibly have access to this high privilege level account !

Instead, I prefer to create a new account and grant access to that account to that share at the NTFS levek. I also remove the account from the Domain Users group and add it to a “No Access” group. This prevents the account being used to access information shared to domain users. It does not prevent it being used to access data shared to everyone or authenticated users though so the amount of protection this strategy supplies will depend on your internal environment. For those shares, access can be denied to the “No Access” group securing the environment once more.

 

He account is granted read access to the share and the built in users group removed. In this way admins still have access to the share but standard users do not and so the likelihood of someone “seeing” any user names or passwords in the customsettings.ini or bootstrap.ini files are limited.

 

Applying these settings, my boostrap.ini file therefore looks as below:

 

Once the boorstrap.ini file has been updated, we need to update the deployment share (to regenerate the WinPE boot .iso and .wim files) and then redeploy those, either to DVD / USB sticks or to WDS as needed. That is, we run the “Update Deployment Share” as below and once that is completed (after 15 – 20 minutes) we copy the files created from the “D:\DeploymentShare\Boot” location to wherever we will be using them to boot our endpoints.

 

Once the boot.ini file has been updated, we can re-test out deployment and ensure that the keyboard set to be used is the correct language (in my case, British English) and that we are not asked for a user name and password to connect to the deployment share. If you prefer you can leave out the line that passes the Password through. In that case anyone accessing the setup screen will not be able to reuse your image without first entering the password. However, if you would like remote users to self service their rebuilds then this would mean you would need to tell them the password so it’s a little bit of “swings and roundabouts” and how you configure this will, to an extent, depend on your circumstances.

Assuming that the test passes, you can now move on to customizing your customsettings.ini file. By default, the customsettings.ini file looks as below:

 

The Information Center provides detailed information on which settings can be applied to the customsettings.ini file. This information can be found by clicking on the “Planning MDT Deployments” link.

 

 

This will open a PDF file and under the “Toolkit Reference | Properties | Providing Properties for Skipped Deployment Wizard Pages” node you will find listed the values you need to enter into customsettings.ini to skip these items in the wizard.

 

 

Accessing the Properties Definition item (1 level up) allows you to get a fuller explanation of each property together with examples of how to configure it.

So, for example, If we want to automatically select the Task Sequence name to be run and just build 2012 R2 servers we enter the two lines below.

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

To automate the complete process you may want to consider using the settings below as well as setting the pre-set items to Yes:

SkipComputerName=YES

SkipDomainMembership=YES

SkipUserData=YES

SkipCapture=YES

DoCapture=NO

SkipLocaleSelection=YES

SkipTaskSequence=NO

SkipTimeZone=YES

SkipApplications=YES

SkipSummary=YES

TimeZone=085

TimeZoneName=GMT Standard Time

 

The Time Zone values for all regions are listed at http://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx.

The above settings will allow you to select a task sequence to be run but will assign a random name to the computer and, unless your task sequence adds the computer to the domain, will add the computer to a workgroup. If you want to pre-set any of the values you add the corresponding entry from the right hand column of the above table and assign a value to it as demonstrated by the task sequence example above.

A completed “basic” customsettings.ini file which would allow you to select the task sequence to apply would therefore look like the below:

Booting using our boot media now results in a single screen asking us which task sequence we would like to run.

 

 

The only thing is, configuring MDT as above means that ALL of your deployments must be identical other than the contents of the task sequence. Now, this may or may not be OK. For example, if we want to use MDT to refresh workstations and laptops as well as build new servers it could be that, when we are booting to a client machine we want to preserver (or be asked to preserve) user data whereas if we are booting to a server machine then we will not want to be given this option. This can be achieved by detecting (gathering) information about the endpoint at boot time and then applying different settings based on characteristics of the endpoint.

Luckily, this isn’t as different as it may sound. When the boot process runs, MDT runs a gather script named ZTIGather.vbs. This script is located in the Scripts folder of the deployment share meaning we can run it ourselves against an existing client and inspect the output of the script quite easily.

 

We can then use those discovered values to drive our deployment proves using customsettings.ini. If we run the script it creates a folder called MININT in the root of the operating system drive.

 

 

Drilling down inside that folder we eventually get to the ZTIGather.log file created.

 

This can be opened in notepad or you can download the SCCM 2007 log reader as part of the System Center Configuration Manager 2007 Toolkit V2 from http://www.microsoft.com/en-us/download/details.aspx?id=9257. This will allow you to install the “Trace32” application (the log file reader) by selecting to install “Common Tools” only.

 

 

An example of the type of information gathered is displayed below.

 

 

As can be seen, we can see whether the device is a laptop, desktop or server architecture, the make and model of the machine, the amount of RAM, processor speed etc. This can therefore allow us to use these values to determine the endpoint type which in turn allows us to determine what happens in our deployment based on the endpoint itself. For example, we can auto select the task sequence to run based on the endpoint type. We can also read items such as the endpoints IP address or gateway address. If we know the gateway address we can determine which site the endpoint is in. If we know which site it is in we may know which department it is in (if the LAN is subnetted in that way) or, in the alternative, which country it is in allowing us to determine which language packs should be installed.

A sample deployment decision tree may look like the below:

 

 

To accommodate this, we create additional sections within our customsettings.ini file. The first thing we do is create a new section which we will call [ClientType]. We then give that the highest priority of sections to be parsed.

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

 

In the [ClientType] section we have instructed the file to go to a subsection named either Server-True or Server-False based on the value of IsServer in the ZTIGather.log file. This leads us to have 2 additional sections – [Server-True] and [Server-False].

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

 

From the above we can see that if the IsServer value is true then we will build using the WIN2K12R2-001 task sequence. If the endpoint is not a server then it must either be a desktop or a laptop so we then query the IsDesktop value. Based on that value we will either be directed to the [Desktop-True] or the [Desktop-False] section.

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

 

If the device is a desktop, the HP task sequence will be run, if not, we will progress to a subsection based on the make of the device – either [Dell] or [Lenovo], the two types of laptops we have in use

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

 

These settings are also accompanied by our [Default] section to cover those items which are not picked up by the above and also to supply the balance of settings. So, our complete customsettings.ini file will look as below:

 

[Settings]

Priority=ClientType,Default

Properties=MyCustomProperty

[ClientType]

SubSection=Server-%IsServer%

[Server-True]

SkiptaskSequence=Yes

TaskSequenceID=WIN2k12R2-001

[Server-False]

Subsection=Desktop-%IsDesktop%

[Desktop-True]

SkiptaskSequence=Yes

TaskSequenceID=HPDesktop-001

[Desktop-False]

SubSection=%make%

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

[Default]

OSInstall=Y

SkipCapture=YES

SkipAdminPassword=YES

SkipProductKey=YES

SkipComputerBackup=YES

SkipBitLocker=YES

SkipComputerName=YES

SkipDomainMembership=YES

SkipUserData=YES

SkipCapture=YES

DoCapture=NO

SkipLocaleSelection=YES

SkipTaskSequence=NO

SkipTimeZone=YES

SkipApplications=YES

SkipSummary=YES

TimeZone=085

TimeZoneName=GMT Standard Time

 

In our [Default] section we have set SkipTaskSequence=NO so that the full list of task sequences will be displayed if an unknown endpoint type is used.

NOTE: The above may or may not work for you – it is merely shown as an example of how to automate the deployment process. The best advice is to start the boot process for MDT and then press F8 to access a command prompt and then read the ZTIGather.log file. You will then be able to see exactly what values and settings will be detected by the boot process (information gathering process) for each end point type. The above process flow can be simplified for very basic deployments by just creating section names based on endpoint attributes such as make, model, serial number, MAC address etc. In this way an appropriate task sequence can be applied to each machine type with separate settings applied to individual machines. For example:

 

[Settings]

Priority= SerialNumber,Make,Default

[AFD1258E]

MandatoryApplications001={GUID}

[Dell]

SkiptaskSequence=Yes

TaskSequenceID=DellLaptop-001

[Lenovo]

SkiptaskSequence=Yes

TaskSequenceID=LenovoLaptop-001

 

Here, we apply the task sequence based on the make of machine. However, on the CEO’s laptop we want to always install a piece of software whenever it is rebuilt and so we record the serial number of his machine and assign the application to that serial number. The GUID is the GUID displayed in the application we have imported into MDT (example below). The GUID needs to be enclosed by the braces, { and }, when being entered in the customsettings.ini file.

 

Indeed, if this application is ONLY to be installed by particular people (and hence automatically) we can tick the “Hide this application in the Deployment Wizard” check box to ensure that it is not offered mistakenly to unknown machines.

As well as using discovered values in this way we can also use items such as the endpoints default gateway to determine what to install, for example language packs. Below is an example of how to configure the customsettings.ini file based on default gateways.

 

[Settings]

Priority=DefaultGateway, Default

[DefaultGateway]

10.1.1.1=LONDON

10.2.2.1=TOKYO

10.3.3.1=NEWYORK

[LONDON]

Packages001=XXX00004:Program4

Packages002=XXX00005:Program5

[TOKYO]

Packages001=XXX00006:Program6

Packages002=XXX00007:Program7

Packages003=XXX00008:Program8

[NEWYORK]

Packages001=XXX00006:Program4

I’d just like to finish up this post by showing you the settings used to join the endpoint to the domain. Any account used must have the rights to join computers to the domain delegated to it and any other rights removed. Remember, anyone with access to the MDT server hard drive or deployment share will be able to see the user name and password used as they are in clear text which is why I create a separate account for accessing that share and then restricting the permissions to only that account.

 

[NEWYORK]

SkipDomainMembership=NO

JoinDomain=EXAMPLE.COM

DomainAdmin=svc_DomainJoin

DomainAdminDomain=example

DomainAdminPassword=Password01

MachineObjectOU=OU=Computers,OU=NYC,DC=Example,DC=com

 

Here, we have detected from the machines default gateway that it is based in New York and so will join our domain and place the machine in the computers OU under the NYC OU. JoinDomain is the domain we want to join and DomainAdmin, DomainAdminDomain and DomainAdminPassword are the credentials of the account that will be used to join the computer to the domain.

If you want some good examples of customsettings.ini configuration I would refer you to http://scriptimus.wordpress.com/2011/06/23/mdt-2010-sample-customsettings-ini-for-fully-automated-deployments/. While this refers to MDT 2010 they should still work with MDT 2013 and, as above, you can confirm the corrected values from the built in documentation and the examples provided there.

In the next part of this blog series we will be covering off Selection Profiles and application of drivers to endpoints and to the WinPE images used to boot client machines for MDT.

 

 

Install and Configure MDT 2013 (Part 1)

Sunday, December 29th, 2013

This post is just a quick walk through on how to install and configure the Microsoft Deployment Toolkit for the first time. MDT helps you automate the installation of Microsoft Operating Systems including associated drivers, patches and software. It can be extended by using Windows Deployment Services to allow PXE booting to the boot image and automated to minimise user input to allow very Lite Touch installations.

In short, it’s a “free” version of those bits of SCCM that allow you to perform operating system deployments.

MDT 2012 requires two pieces of software to be installed:

  1. The Windows Assessment and Deployment Kit for Windows 8.1
  2. The Microsoft Deployment Toolkit 2013

These can be downloaded from here and here respectively but you may want to search for updated versions.

The 2013 version of the toolkit supports deployment of Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2.

First, we install the Windows ADK for Windows 8.1. When asked select to install the deployment tool, the Windows PE environment and the User State Migration Tool following the prompts to complete the install.

 

When installation has completed, we then install MDT 2013 selecting the default settings.

 

Installation of the ADK and MDT are supported on Windows 2012 / R2 as well as 2008 R2. Once installed we start the workbench application which can be found by searching for “Deployment Workbench”

 

The workbench contains 2 nodes, the Information Centre which contains documentation and Deployment Shares which is the engine of MDT with each share conta9ining a location from which operating systems can be deployed.

 

The first task is to create a new deployment share. This can be done by right clicking the “Deployment Share” node and selecting “New Deployment Share”.

 

Set the share location

 

A name for the deployment share

 

 

And a description

 

 

Next, we select options for the “deployment share”.

 

 

What these options will actually do is begin to make choices for the installation GUI experience. That is, which pages are shown in the installation GUI. In a subsequent post I shall show you how to amend these choices. For now the defaults can be accepted or amended as you see fit.

We can then accept the summary of information and proceed to create the deployment share.

Once the deployment share is created a folder shared with the above details will be created. This folder on the hard drive will contain a selection of sub folders:

This folder structure matches closely what you see within the Deployment Workbench but contains a few additional specialist folders.

MDT is now ready to configure. To make any configuration easier to understand, I first create a folder structure.

 

With our folder structure in place we are now ready to import an operating system. Below I show how to import Windows Server 2012 R2 operating systems ready for deployment but we can just as easily import desktop operating systems.

First, we mount our ISO image and copy the contents to the hard drive. I have created a folder called D:\Sources to hold any source installation files.

With the files extracted, we right click the appropriate sub-folder under Operating Systems (in my case, the Servers sub folder) and select “Import Operating System”.

 

As I have a full set of source files I can select to import a full set of source files.

If we had previously created a reference image, we could then capture it as a master image at which point we would select “Custom image file” instead. If we had an existing WDS infrastructure, we could leverage our work to date and import those existing images using “Windows Deployment Services images”.

NOTE: If importing WDS images, we have to import ALL images. We do not get to select which ones to import though they can be subsequently deleted.

We then browse to the folder we extracted from the DVD. As the source files exist on the same volume as my deployment share I have selected to move the files instead of copying them to speed up the process. If it’s important that the original files are preserved for some reason then you can deselect this option to copy them. If you set the source location as the original DVD then you will have no choice other than to copy the files.

 

 

We can then give the folder to which the images will be copied a meaningful name and proceed with the import.

 

 

My source contains four editions of Windows Server 2012.

 

My source folder is emptied.

 

And the source files are moved to the folder name I selected in my deployment share.

 

The operating Systems now appear in the MDT interface and are available for installation.

 

 

Next, we import any necessary drivers. To create a reference image I shall be using a virtualised environment negating the need for drivers. However, drivers are imported in much the same way as operating system files. Firstly, download and extract the driver files from any executables to obtain the necessary inf files and other associated files. Where drivers cannot be extracted then they may need to be installed as complete applications. As a minimum you should endeavour to extract any network and mass storage drivers to enable the operating system to install and connect to the network.

To import the drivers we right click the appropriate node and choose to “Import Drivers”.

 

We browse to the location containing our extracted drivers (multiple sub folders can exist in this location, one for each driver or set of drivers).

 

 

We can choose to import drivers even if they exist elsewhere. This is useful if we have a structure as shown here (one folder for each model of machine) where multiple models may utilise the same driver. By allowing the driver to be reimported we can ensure that the driver exists in that folder. However, care should be taken when creating any task sequences that only the appropriate copy or version of the driver is installed.

 

 

Our drivers will then be imported.

 

 

We can also import software using the same process. I personally create at least two folders, one named global (top contain software to be deployed to all endpoints) and one name Departments or similar, which then contains a sub folder for each department holding the software appropriate to that department. Other folder structures can be used, you should use whichever method makes it easiest to navigate the structure, especially when it comes to installing end client software.

To install an application we simply right click the folder where we would like to locate the application and then select “New application”.

NOTE: An applications is different from a package. In MDT an application is a piece of software you install, a package is an operating system patch or language pack.

We are the presented with three choices:

 

An application with source files will allow you to install a “standard” application. An application witho9ut source files or one on the network is an “application” that is run directly from a share while an application bundle is merely a placeholder to group together multiple applications that must be installed as a single item.

Here I will install Foxit Enterprise Reader. I quite like this as a PDF reader as it’s faster and, I think, more functional than Adobe.

We complete the details about the application.

 

 

Browse to the location of the application, again selecting to move the application install files.

 

Again, we select a meaningful name for the folder in which the application source files will be placed.

 

 

We then enter the command line to silently install the software. As with all MSI packages, it may be that a transform file is required to install the software. Foxit has a number of switched which can be obtained by mailing the support department at Foxit. The ones we shall user are:

MAKEDEFAULT (When enabled, this setting will make Foxit Reader the default PDF application and will associate all .PDF files with Foxit)

LAUNCHCHECKDEFAULT (When application starts up it will verify that Foxit is the default browser)

VIEW_IN_BROWSER (This will allow PDF files to be read in your web browser)

STARTMENU_SHORTCUT (Place Foxit shortcut in Start menu)

DESKTOP_SHORTCUT (Place FoxIt shortcut on the desktop)
The installation command line we shall use is therefore

msiexec /i “
EnterpriseFoxitReader612.1224_enu.msi” /qn /norestart MAKEDEFAULT=1 LAUNCHCHECKDEFAULT=0 VIEW_IN_BROWSER=1 STARTMENU_SHORTCUT=1 DESKTOP_SHORTCUT=0

A log file of the installation can be taken using the standard msiexec switch /l*v if needed.

NOTE: Note the use of the /norestart switch. As an alternative for windows installer files/ we can use REBOOT=reallysuppress. The application being installed must NOT reboot the computer as part of the installation routine. Any reboots should be handled by MDT so that WinPE can prepare for shutdown and recover from restarts.

 

 

We can then follow the prompts to complete the import of the application. Once imported, it appears in our list of applications.

 

Accessing the properties of the application (by right clicking) exposes the settings we just provided. Here, we can also instruct MDT to reboot the computer after application installation if required.

 

Once we have our operating systems, applications and drivers imported we can move to using MDT to deploy computers or, in the alternative, creating a reference image to be imported which contains all our base software. The reasons for creating a base image containing the software are:

  1. It reduces installation times as the installation (including all software) will be from an image (rather than using installers) and so a fully configured computer can be deployed in ~ 30 minutes rather than the 2 – 3 hours required when using installers (assuming multiple base applications).
  2. It’s a trivial exercise to rebuild or recreate the reference image as the operating system files, drivers and application files already exist within MDT so if we need to update an item of software this is not onerous. This is compared to removing applications from the base build and using a task sequence to install all applications which can take far longer.

To prepare for installing operating systems with MDT we next create a boot image which the computers will use to boot to. This boot image will contain the executables for the MDT GUI and our network and mass storage drivers that we have imported. It also contains some command / configuration files which I shall detail in a later post.

To create the boot media we “update” the deployment share by right clicking the deployment share and selecting “Update Deployment Share”.

 

The WinPE image that ship with the ADK is the one used to create the boot image. Indeed, a number of boot images will be created in each of i386 and x64 variants. You are asked whether you would like to update the existing image to optimise the creation process or completely regenerate the image.

 

As this is the first image being created both options result in the same thing. Working through the process creates the boot image and this process takes around 15 – 20 minutes.

Once complete a number of files will be created in the Boot folder of the deployment share.

If integrating MDT with WDS then the .wim file can be used to boot to from PXE otherwise the .iso file should either be attached (when building a VM) or burning to a CD / USB thumb drive for direct booting.

The final thing we need to do is to create a task sequence for the MDT GUI to follow. This lists the tasks that will be followed to create a base image. For our purposes, a default task sequence can be used. I shall try and detail how to bespoke the task sequence in later posts.

To create a new task file we right click the appropriate folder and select “New Task Sequence”

We give the task sequence a name.

We next select a template to build the task sequence from.

 

 

If we have a pre-existing computer to use as a reference image we can just select “sysprep and capture”. If we have a pre-prepared VHD and don’t own SCVMM, we can select one of the later task sequences.

As I have a server O/S to deploy I shall choose “Standard Server Task Sequence”. If we were installing a desktop O/S we would simply select the very similar “Standard Client Task Sequence”.

We then select the operating system that we would like to install using this task sequence.

 

If using a KMS enabled copy of the operating system disk we can simply select not to use a key at this time

 

If we are using a retail disk (such as those from MSDN) then we can enter a retail key or if we have MAK keys then we can select the second option.

We next provide the standard Windows information – here I have set the IE home page to the internal intranet but for a server you may want to leave at the default “about:blank”.

 

Next, we can either specify a local administrator password (the default option) or choose to supply one at the time of deployment.

 

Once completed, the task sequence appears in the MDT GUI.

 

 

 

The physical files constituting the task sequence can be found in the Control folder of the deployment share.

 

 

 

We can now build and capture our reference machine. I do this in a virtualised environment to remove any reliance on network or mass storage drivers. We simply mount the LiteTouch ISO to the VM and boot it.

 

The VM will boot to the WinPE / LiteTouch ISO created earlier and the GUI start to enable installation.

 

You are presented with various options such as being able to set a static IP address if your virtualised environment does not connect to DHCP (as some production based server environments do not) or running the windows recovery wizard. If you need access to a command prompt, simply press F8. This will allow you to inspect the local hard drive or any installation logs.

NOTE: The computer will NOT reboot / the process will NOT complete while the command prompt it open. This should be closed when not in use to allow the build to complete.

If we choose to run the deployment wizard we are next asked for credentials to use to connect to the deployment share.

 

The wizard then ask which Task Sequence should be used to deploy the machine.

 

We are then asked if we would like to join a domain or a workgroup – for a reference image I would recommend joining a workgroup to ensure that no remnants of the domain membership are “left behind” once the image is taken.

 

 

We then set the language and time zone for the server.

 

 

Select any applications to be installed. Here I am selecting Foxit, as a demonstration, even though this is unlikely to be installed in a server reference image. For a client reference image you may want to consider installing items such as C++ redistributables, Silverlight etc.

 

 

As we are creating a master image (from the reference image we are deploying) I have selected to capture an image. Once this captured image has been imported as a reference image for deployment, we would simply select “Do not capture an image of this computer” to deploy additional machines.

 

 

As we are deploying to a virtual machine, the choice to deploy bitlocker is skipped over. We can now click on “Begin” to start the automated installation and capture routine.

 

 

And that’s it – a basic installation and configuration of WDS so that you can deploy, capture and redeploy desktops free gratis and for nothing (well, you will need a server to run the software but most organisations have capacity for this in their virtualised environment).

In part 2 of this series I run though automating the environment even more and show you how to cope when you have a variety of endpoints to deploy to.

System Center Service Accounts

Thursday, December 26th, 2013

There’s a very good list of all of the service accounts required for System Center 2012 at http://systemscentre.blogspot.co.uk/2012/05/system-cennter-2012-service-accounts.html.

Start Remote Powershell from Taskpad View

Tuesday, December 24th, 2013

If you have been administrating a Windows environment for a while you probably realise the power of creating task pad views within an MMC to remotely administrate your computers. For example, you can add an MMC console to connect to Active Directory Users and Computers and create a query containing all computer objects. This then allows you to have a dynamic list of all computers and create a task pad view with nuggets if functionality allowing you to connect with and control those computers.

lab2

If you want to start a remote Powershell session with a selected computer, create the task as below:

lab

The -noexit switch ensures that the Powershell window stays open once you have connected.

 

 

 

 

Setting up Active Directory for DR

Monday, December 23rd, 2013

When setting up a Disaster Recovery site its reasonably standard to deploy Active Directory in that site and let AD replicate as usual to ensure that you have a copy of the directory available.

However, replication between sites (using site links0 can only occur as often as once every 15 minutes, longer if you don’t change the defaults. This means that, if the disaster occurs in that time period, any changes that you make may well be lost.

To overcome this you can set up change based notifications for the site link. This makes updates between sites work as though they are within the same AD site. that is, pretty much as soon as a change occurs, it will replicate across the link. of course, this will generate more traffic between links especially for larger sites but you tend to ind that a DR replication link is usually fairly fast and low latency to allow replication of the virtual machines and data.

To enable notification driven replication between active directory sites, access the site link properties page and update the “options” value.

lab3

The options attribute uses a bitmap. Its possible values are:

Decimal Value Binary Value Explanation
1 1 USE_NOTIFY
2 10 TWOWAY_SYNC
4 100 DISABLE_COMPRESSION

If you want to enable notification without compression (as you are on a LAN like connection, for example, between firewalled segments of the LAN) you can enter the value 5 to enable notification without compression.

Windows Server 2012 R2 Data Deduplication in Action

Saturday, December 14th, 2013

Must say, I’m most impressed with Windows 2012 R2 data deduplication. I am using it in my home lab and can now have far more VMs on standby ready to go with technology specific labs switched off but consuming very little space. Below are the results that I am getting so this is “real world” with most of the VMs running the same operating system.

 

 

That’s a total of 54 VMs, ISOs and templates taking up only 133GB of space !

To enable this feature, open up Server Manager and navigate to the File and Storage Services node then select the disk on which you want to enable deduplication (dedupe is only supported for flat files and VHDs so don’t try and dedupe the disk with your operating system on).

Right click the disk and select “Configure Data Deduplication”.

 

 

The single pane of settings is then fairly self explanatory.

 

 

As you can see, mine is set to deduplicate VMs so I have excluded n0n-VM files such as anything in the ISOs folder. I can’t say that I have seen performance suffer enabling this but I am just running in a lab and not in production but it seems to me that, with shared storage being so expensive and performance being so critical, it now makes sense to place SSDs in your SAN and put your deduped VMs on those for maximum performance at reduced cost.

Want to know which Active Directory Groups you are a member of ?

Thursday, December 12th, 2013

If you want to know which Active Directory Groups you are a member of and you do not have access to AD, simply open up a command prompt and type

whoami /groups

Nice little trick if you are doing deskside support and want to quickly check that the user is in the right groups