If you've been following my series of blog posts, you know I've been walking through alternative ways to deploy an OS. (If you haven't been following my series, here are links to the first two posts: http://blogs.msdn.com/b/customer_reviews_of_stb_products/archive/2013/03/11/os-deployment-system-center-configuration-manager-2012-or-microsoft-deployment-toolkit-or-both-by-dujon-walsham.aspx and http://blogs.msdn.com/b/customer_reviews_of_stb_products/archive/2013/04/07/system-center-2012-or-microsoft-deployment-toolkit-for-os-deployment-part-2-by-dujon-walsham.aspx.) This third part will now focus on showing the theoretical design. I'll now put in place everything I explained in the previous parts, and explain each step and how it contributes to the design of the true zero-touch interface (ZTI).
Each section below will look at the mechanism changes , starting off with the current state mechanism in the light-touch mode.
So far we've been looking at the default setup of trying to build a standard machine without any additional setup whatsoever. This means that this is currently in a light-touch state, rather than a zero-touch state--that is, it will require some light participation from either you to perform the build. So if we go ahead and try to build a machine with these settings so far, here is what we get: Figure1.1 – MDT Wizard Welcome Screen
Figure 1.2 – User Credentials
Figure 1.3 – Task Sequence
These are some of the windows you would see when building a machine, as well as a few others that are related
The reason for displaying this is to show the amount of effort involved in a light-touch scenario, which is perfectly acceptable if you're just building a few machines. But for a mass deployment, this can be a lot of work..
Let's now elaborate on all the functions we will use to display how we will use a true ZTI.
Let’s dive into the rules and Bootstrap.ini of our MDT environment:
Now we can see the default settings:
Figure 2.1 – MDT Rules
This is pretty standard. So if we analyse under the [Default], we can see a list which outlines the Wizard screens which you do not see as they have “Skip” as a prefix and yes as the answer to skip them.
One of the big drivers in ZTI is to eliminate the need to go through the wizard screens above and have them already pre-configured. This way users or staff do not have to be present during the deployment--at least when the deployment is going successfully, anyway.
So the next step here would be to enter the other steps to skip the screens above.
Then you will see the MDT Rules look like this:
Figure 2.2 – Newly added MDT Rules
And next step is the Bootstrap.ini, which will be used to pre-configure domain membership credentials so that this is also automated. This will eliminate the need for the steps in Figure 1.2
And we will add the following:
So it should now look like this:
Figure 2.3 – Bootstrap.ini. Admin password blanked out for security reasons
After completing this, we now have silenced all of the windows in the Deployment wizard from the light-touch experience. This was first step. Of course if you tried to build a machine in this current state, it would just reboot as all the windows have nothing selected. So stripping the MDT rules shown earlier would bring this back to life if needed .That ability can be very handy for troubleshooting purposes. So we have now avoided the MDT wizard screens explained earlier.
The screenshot below shows the Task Sequences. These are standard Task Sequences that contain vanilla OSs, with no applications.
Figure 3.1 – Task Sequences layout
So this includes everything from
Now we dive into each task sequence: Desktop OS (Windows 7/8) and a Server OS (Windows Server 2008/2012)
One reasons for this is to plant some seeds that will allow us to control the customization of the deployments from a Web Frontend interface. For example, a feature we would love to control on demand is the addition of applications.
Figure 3.1a – Server OS Task Sequence steps (With Server Role Setups). Pre-Staged actions for ADDS, DHCP, & DNS as well as the “Install Application” and “Install Roles and Features
Figure 3.2 – Desktop OS Task Sequence which has “Install Roles and Features” and “Install Applications” steps pre-staged
Here we have the list of applications that are added into the MDT console. These will also play a vital role in the customization and flexibility of options for deployment. Figure 3.3 shows some applications that have been gathered, and you will see these again later.
Figure 3.3 – Applications Layout
The whole idea and reasoning for creating them this way is to achieve flexibility of deployment options, so we can deploy from vanilla, to hybrid and customized builds with-on demand options to customize them. Your company-standard Task Sequence will contain customized actions that would be used for any base image and, requirements for the desktop environment.
This is an integral step, in every sense. Here is where we establish a connection to the database server to create its own database that we will use to store the clients' details, These will be referenced when it comes to the Task Sequences being deployed to the clients.
Now we should see some details for our database connection below, as well as some more options for us to play with:
Figure 4.1 – Database configuration with additional folders listed below
Now we have further options available to us called Database Rules. We currently have an additional four folders:
These contain a series of rules that are processed in priority order.
In the MDT Console right click the Database and click Configure database rules.
You can tick and untick where appropriate. In this case I’m more concerned with the Computer rules. These rules are normally processed one-by-one with the first one, of course, being the main priority. In this case we need to change this order so it can reflect how we want our customizations processed. So currently, this how the rules are laid out in the bootstrap.ini:Figure 4.6 – Bootstrap Settings after Database rules have been configured
If you're adding any other rules, then make sure that these stay ahead. One little hurdle is, of course, the authentication between the SQL Server database and the MDT server. This would prompt us to create a SQL Server login that will authenticate with the database.
1. Log on to your SQL Server 2. Open a connection to your SQL Server with the SQL management studio3. Go to Security – Logins. Then right click and choose New Login4. Provide a name and password and check the SQL Server Authentication box. Untick password expiration (you’ll thank me later) and select the database default to the MDT database5. Click the Server roles tab and choose sysadmin role and click OK to finish6. Right click your SQL server name in the SQL Management Studio console and choose properties. And go to the security tab and ensure that it has SQL Server and Windows Authentication checked
Now when we return back to the bootstrap.ini further down, we can see additional entries regarding the Computer rules.Figure 4.7 – Bootstrap.ini settings with database rules configuration
So what we need to do now is add the SQL Server login and password like we created earlier so that it looks like Figure 4.8. This has to be done on each part. Figure 4.8 – Bootstrap.ini with Database rules, which require the SQL Server login credentials
The DBID and DPWD values must be placed below each Database rule shown in the bootstrap.ini. Then update deployment share to generate boot images that reflect this:Right click the Deployment share, and choose Update Deployment share. This will generate the boot images with the new configurations, and these can be addedinto the WDS Server again.
To do this, open your WDS console and perform the following
Once we click to add a new record, we see for options that will allow the machine to be picked up by the SQL Server database:
The form contains all the raw values that make up all the settings, either compulsory or optional, that reflect how a machine will be built by either the task sequence or the options you choose with the MDT Deployment wizard. So values we would most probably need would include:
You can get away with pre-configuring the values for these variables within the form to build your machine fully automated. Figure 4.9 – MDT 2012 Database form
Downside: Although it is very useful, you may find it's very non-user friendly due to the raw material of variable names, as well as the fact that you need specific values that refer directly to the variables listed. And this is where the good stuff comes in.
We now have the foundation ability to build machines using ZTI. We can have machines detected on the network by variable methods within the SQL Server database. Of course, I would like to address the main downside that will be the icing on the cake for this solution. MDT Web Frontend Setup
First, let me start by saying this magnificent tool was created by Maik Koster. The installation guide can be found here: http://mdtwebfrontend.codeplex.com/wikipage?title=Installation%20Guide&referringTitle=Documentation. This tool really adds to the overall design and feel for this.First off once we bring up the first screen, we need to enter the details of our SQL Server Database server name and Database. Then we need to tick both boxes and click to Upgrade Database. Settings will automatically be saved. Figure 5.1 – Opening page to set up your Database connection Once this has been set up, we can now begin the building blocks to form the UI for true ZTI design.
Task Sequences: You will now see how we develop the whole user friendly interface. Starting from here is where we create a list of entries that will contain the variables needed to refer to the database form shown earlier. So when we create a list here, we then use the two fields as follows:Name – Name of the Operating System (any name you wish)
Value – Task Sequence ID in the MDT console
So if we refer back to the MDT Console where we have our task sequences created, we see that they all contain a Task Sequence ID, which is their variable. And if we look at the database form above, we can see where it has “TaskSequenceID” listed. So once we make entries within our list, we can make the variables into simpler choices by providing them with a friendly name for the Task Sequence IDs to be similar to the friendly names of the Task Sequences within the MDT Console.
Languages – Now here is an interesting one. Sometimes you may experience issues with trying to select the default languages when building machines. Most are US English by default but have sometimes caused complications when I was setting this inside the answer file “unattend.xml.” So I have created a list that focuses on the languages we are most likely to flip through, which would be U.K English or U.S. English.
Name – Name of LanguageValue – Value Locale ID. These can be obtained from here http://msdn.microsoft.com/en-gb/goglobal/bb895996.aspxOS Roles/OS Role Services/OS Features – Another little addition we can choose is the ability to add OS Roles/Features on demand. Of course little drawbacks include things like the fact that you cannot refer to multiple roles or features in the same values without using “,” between them. So if you want to use this method, you can either use one value or string up multiple to make one value.
Name – Name of OS RoleValue – Role Name in PowerShell context. Can be found using this http://technet.microsoft.com/en-us/library/cc732757.aspx#BKMK_wps or using a PowerShell command Get-WindowsFeature (Note: if using Windows Server 2008, then run Import-Module ServerManager first)Name – Name of OS FeatureValue – OS Feature Name in PowerShell context. Can be found using this http://technet.microsoft.com/en-us/library/cc732757.aspx#BKMK_wps or using a PowerShell command Get-WindowsFeature (Note: if using Windows Server 2008 then run Import-Module ServerManager first)Name – Name of OS Role ServicesValue - OS Role Service Name in PowerShell context. Can be found using this http://technet.microsoft.com/en-us/library/cc732757.aspx#BKMK_wps or using a PowerShell command Get-WindowsFeature (Note: if using Windows Server 2008 then run Import-Module ServerManager first)
Categories: Here we will construct the user friendly form used to build machines. The first one, we will label as Machine Details, which will have the values below:
Computer Name – Computer Name
The next form will be the Network Details, which provides fields used to join the domain:
The next form will be Additional Roles, where you will choose your Roles/Role Services and OS Features if required:
Then the final one is Additional Roles continued, which is optional as this will contain options to build Primary server role functions such as Domain Controllers, DHCP servers and DNS Servers.
Administration – Groups
In this tab, we will now group together all the sections to create one big form which will contain the following:
Let’s take an opportunity to create another group with similar categories but this time we’ll add a few more. This will tie in more with the Task Sequences that have the Server Role Setup groups so that we can configure additional server roles such as the Domain Controller, DHCP, and DNS Servers:
Administration – UsersAdd users here from your domain to control access to the MDT Web Front end.Administration – Access RolesHere is where we can set our newly constructed form to be in use by default, which we can do by clicking the Edit button and choosing our Group as the GroupID. Click save (Note: We can create different forms and assign them to different users, but that will be described later in the final part of this series of articles.)
Here we can upload all of our applications that are in the MDT console and load them into the MDT Web Front End for easy selection. In this section, click the Upload applications.xml and select it by going to Deployment Share\Control\Applications.xml, and choose Upload.
Figure 5.2 – Application list uploaded
Now you can see all the applications we have within the console
Computers – Add New Record
Once we click to add a new record, we are presented with four options that will allow the machine to be picked up by the SQL Server database:
You may find MAC address easier for virtual machines and find serial numbers easily for physical machines. But make sure you verify the serial number in the physical machine BIOS also, as they might not always match, and any serial number within the BIOS will always be correct.
And now below is our newly constructed form. Now once we edit, we can now populate the entire form and build our machine in a preconfigured friendly manner.
Figure 5.4 – Our new form for building machines
Now, in the other form, we can see we have additional configurations:
Figure 5.5 – Doman Controller Settings
Figure 5.6 – DHCP Server Settings
Figure 5.7 – DNS Server Settings
So with these additional settings we can build Domain Controllers, DHCP Servers, and DNS servers--just from this form alone.
(Note: you must install the server roles first. You can choose to do this on demand in the Web Front End or just configure it inside the base task sequence for a Server OS that has the Server Role Setups group inside)
With the pre-configured “Install Applications” step in the Task Sequence we did earlier, we can now choose applications within this tab to add on demand.
With the whole UI constructed in a web portal, we have now made customization of the build process and on-demand features in such a user friendly way as to eliminates a lot of the administrative effort needed that could result in multiple task sequences and various steps.
We now have True ZTI in full effect now, with foundation Task Sequences with steps that allow us to control on demand. We have customized features that are fully automated without user interaction. And all machine builds are referenced through the SQL Server database and stored in the SQL Server database.
So now give this a try by building a machine, and it should just flow through without any issues at all--hopefully. But the end result should be a painless and easy machine build through a web form.
One drawback which you may experience is once a machine is built its record stays intact in the web front end, as well as its preferred method to detect it on the network. This means that if a machine were to accidently PXE boot into the MDT server, it could rebuild over the whole machine. Well I’m sure nobody wants to do this sothere are two options:
You can take the time to either delete the records with the Computers tab in the MDT web front end or simply remove either its MAC Address, UUID, Serial Number, or asset tag and just type the word “Blank” to prevent this.
In the WDS Server we can enable pre-staging clients similar to the System Center Configuration Manager console by configuring Windows Deployment Services (WDS) to allow only known clients as shown below:
Figure 5.8 – WDS Tab for PXE Response
Then go to the Active Directory PreStage Devices and right click and choose Add Device
This has been a long article, but I hope it provides a lot of valuable information and step-by-step instructions. The last part of this series will be short and will just run through the other stuff you can do with the MDT Web Front End in this scenario. I'll analyse more of the Role Options, Locations, Make and Model.