I’ve been doing server monitoring for 10 years now – initially with NetIQ AppManager – and since the end of 2009, with Microsoft System Center Operations Manager 2007 R2. Now I’m using System Center Operations Manager 2012. I also checked other tools from HP, BMC, IBM before we moved to Operations Manager. So why did we select it?

First of all: It was cheaper than the solution we had and than the other tools we evaluated, with nearly the same functionality (there are always small differences). It had a centralized console and not that many components, and it was easy to administer. I especially liked the possibility to use PowerShell for administration and scripting. And we already used System Center Configuration Manager in our environment, so it was only a small step to extend the System Center suite here.

When we implemented System Center Operations Manager, it only supported a few other operating systems besides Microsoft Windows. This has changed within the last years. But the strength remains the same. In addition, the System Center product is now on the same launch cycle as Windows Server, and it looks like SQL Server will also be on the same schedule. So the integration and support with Microsoft enterprise software is very high.

One main difference compared to NetIQ AppManager was that you only needed to install one agent, and all other components got deployed through the management packs. So you did not (and still don’t) need to install agents for Active Directory, SQL Server or other products. That was always hard to maintain with NetIQ AppManager. And perhaps the biggest difference was and is—System Center Operations Manager is stable! That sounds weird but that fact broke the neck of AppManager in our environment. You need to trust your monitoring solution. If the trust is gone, then you do not need the tool anymore.

Another difference in Operations Manager was that creating custom monitoring with your own management packs was well documented and relatively easy to do directly within the console or in more details with the 2007 R2 Authoring Console or XML. That has changed in Operations Manager 2012; the Authoring Console is gone and replaced by Visual Studio. It was a pain at the beginning, but is getting better every month (with more options in Visual Studio and better documentation).

I also liked the great community on the Internet. It has a lot of very good information besides the official documentation and is growing every day. It is really hard to stay up to date with knowledge, especially when you see how often Microsoft now launches new versions or provides rollup updates.

Microsoft has implemented a lot of new functionality into Operations Manager within the last years. They focused on implementing .Net APM monitoring (bought from Avicode), restructuring and improving network monitoring, implementing the Global Services Monitor, Windows Azure and System Center Advisor. The downside is that network monitoring, in particular, brought up problems for existing customers who had used this functionality before because the management packs had to be rewritten. The documentation is this area still needs improvement.

Besides all this new functionality and implemented break fixes I – and definitely a lot of other customers – am still missing some basic updates, like for the Maintenance Mode. There is no integrated solution to set the maintenance mode directly from the agent or schedule it on a recurring basis. Yes, there are a lot of community options (see also my option) and there is a Reskit tool for it, but nothing in the standard product.

Operations Manager also has some other functionality I want to mention here. For example,  Agentless Exception Monitoring (AEM ) lets you centrally collect and monitor application exceptions. (AEM was formerly known as Dr. Watson alerts.) Another one is Audit Collection Services (ACS) for central log collection. We do not use these two features, and I think there are not a lot companies that utilize it, but I want to note that they are available and can be implemented.

The real power of System Center is the integration between the System Center components and all other Microsoft products. The Microsoft management packs for Operations Manager are free, and a lot of other vendors provide integration.

Microsoft and the Private Cloud

Microsoft is pushing the Private Cloud idea with System Center. I think System Center is a great toolset for this, with its integration between the components, and Private Cloud is a future-oriented vision. But most customers are not ready for it yet. We are still stuck in the old server-oriented administration and monitoring processes. It will take some more years to see this change in real life. Currently the Private Cloud functionality is mainly used by ISPs.

Microsoft provided the required basis for the Private Cloud with the change of the System Center licensing. When you start with System Center, you get the whole suite now and since you have the licenses for all products, why shouldn’t you start to try and test all products? It is as if you buy a car and get 5 more cars for free. Would you leave them unused only because you have to pay for the gas?

The review reflects my experience with System Center Operations Manager. I hope my views are helpful to other systems administrators.

Unfortunately, there aren’t too many ways around such tasks besides checking the references manually in each task sequence to identify if the application/package resides here.  Of course, with the right practices you may have change logs and records of each change and step within each Task Sequence. But if not, or for an easier alternative, you can use a PowerShell script that uses WMI queries within the Configuration Manager SDK. Below is the script:

$Application = Read-Host "Name of Application"

$ApplicationResult = Get-WMIObject -NameSpace "root\SMS\Site_(SITECODE)" -Class SMS_Application | Where-Object {$_.LocalizedDisplayname -eq $Application} | Where-Object {$_.NumberofDependentTS -gt "0"}

$AppID = $ApplicationResult.CI_ID

$TSDependents = Get-WMIObject -NameSpace "Root\SMS\Site_(SITECODE)" -Class SMS_TaskSequenceAppReferencesInfo | Where-Object {$_.RefAppCI_ID -eq $AppID}

$ConfigurationManager = "C:\Program Files\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1"

Import-Module $ConfigurationManager

Set-Location (SITECODE):

$TSNames = $TSDependents | ForEach-Object {$_.PackageID} {Get-CMTaskSequence
-Id $_.PackageID}

Write-Host $TSNames.name

PowerShell Script Breakdown

I normally like to give a breakdown of each step so you can see the development of how it all works and comes together. So I will explain how the script works, both from a single application perspective and from a bulk application perspective.

Single Application Perspective

1. The script asks for the friendly name of the application (i.e., how it’s displayed within the Configuration Manager console).
2. It will then pull the
   application from the SMS WMI class and filter it to where it has dependencies. As applications are revised, it records when changes are made, as well as adding to Task Sequences, Application/Package dependencies, etc.
3. It will then pull the CI_ID for the application, which is needed in order to get the SMS WMI class to identify the application
4. It will pull all of the Task Sequences in which the application is referenced. At this point, it shows the Package ID of the Task Sequences they belong to. Though this is a great deal, why not take this a step further by finding its exact, friendly TS Name?
5. It will then import the module for the Configuration Manager so we can utilize its cmdlets.
6. It will then produce a list of all of the Task Sequences in which the application is referenced by the Task Sequence’s friendly name

Bulk Application Perspective

For bulk applications, this works in the same way, but you can use a CSV file if you already have a list of all the applications. This can be pulled from the reporting side of Configuration Manager and saved as a CSV File.

You could just remove the first two lines of the script below, with something like:



$CSV = Import-CSV (Path of CSV File)

$ApplicationResult = $CSV | ForEach-Object {$_.LocalizedDisplayName} { Get-WMIObject -NameSpace "root\SMS\Site_UCL" -Class SMS_Application |
Where-Object {$_.LocalizedDisplayname -eq $App1} | Where-Object {$_.NumberofDependentTS -gt "0"}

(Package References)

This can also be used to reference packages.

I hope you find these tips useful. They’ve worked well for me. If you have PowerShell scripts that you use with System Center, please share them.

1. Can GeoFlow connect to SQL Server Database?
2. Can GeoFlow connect to SQL Server Tabular Model?

The answer to both of these questions is "Yes" - but indirectly. Let us go through the basics of GeoFlow first.

The Basics: Data Model for GeoFlow (Public Preview)

GeoFlow makes use of the Data Model definition that is defined on the Excel 2013 workbook, which can be modified and managed in PowerPivot. GeoFlow actually only makes use of the columns and calculated columns in PowerPivot. This means that a plain table that has been added to the Data Model in the workbook, would be in PowerPivot, including the data, and is accessible by GeoFlow. In addition, GeoFlow recognizes relationships in the data model as outlined later in this article.

Can GeoFlow connect to SQL Server Database? 

Yes, it certainly can. PowerPivot can be used to import one or more tables from SQL Server database, which can in turn then be consumed by GeoFlow. In fact it is a good idea to use PowerPivot to model the data first. 

To do this:

1. Create a new Excel 2013 workbook. Click on the PowerPivot tab and choose Manage to launch PowerPivot.

2. On the PowerPivot window, click on the Get External Data button which allows you to choose how to connect to your data source. As we are aiming at connecting to a SQL Server database, click on Get Exeternal Data > From Database > From SQL Server, which will launch the Table Import Wizard dialog box.

3. In the Table Import Wizard dialog box, enter the connection details similar to below. From here the steps of adding data into PowerPivot is similar to as the one described in https://technet.microsoft.com/en-us/library/gg399137.aspx

Writing a query against the database to add data into PowerPivot is also an option. 

4. From here, you can continue enriching the data model in PowerPivot. However, GeoFlow will only make use of the columns defined in PowerPivot, including calculated columns. 

Below is an example of a calculated column to concatenate City, Region and Country values that can be used later in GeoFlow. 

5. Once the data model is defined, jump back to Excel 2013, go to Insert > GeoFlow and create a new GeoFlow tour. Now you are all set to go with exploring geographical data in GeoFlow. 

At the time of writing, GeoFlow does not support SQL Server spatial data type. So in order to make use of data in SQL Server, GeoFlow accepts the following format:

• Text form (City, Country, Region, Address, Street, … Other) 
• Latitude and Longitude coordinates. 

Tip: In some cases, it may be a good idea to add a new calculated column which contains concatenated Locality columns as mentioned in Step 4. GeoFlow uses Bing to map the geographical information provided, based on the classification setting. The following "Locality" calculated column is created to provide better mapping accuracy.

Below is a screenshot of GeoFlow working area based on data sources from SQL Server tables, with over 22 Millions of rows.

This particular example actually takes a couple of minutes to refresh the 22 Million of rows. so if you have a large data set in a SQL Server database, it is possible to map it in GeoFlow. 

Can GeoFlow connect to SQL Server Tabular Model?

Yes, it can. Using PowerPivot, we can import the data from Tabular Model in a tabular format. Please note that the model or the definition of the Tabular Model cannot be imported into Tabular Model, such as KPI information, calculated measure. You can use DAX or MDX to import the data from Tabular Model into PowerPivot. 

Below is a step by step list to get the data from Analysis Services into PowerPivot, which in turn is accessible by GeoFlow.

1. Create a new Excel 2013 workbook. Click on the PowerPivot tab and choose Manage to launch PowerPivot.

2. On the PowerPivot window, click on the Get External Data button which allows you to choose how to connect to your data source. As we are aiming at connecting to an Analysis Services Tabular Model instance, click on Get Exeternal Data > From Database > From Analysis Services or Power Pivot, which will open up Table Import Wizard dialog box.

3. In the Table Import Wizard dialog box, enter the connection details similar to below. From here the steps of adding data into PowerPivot is similar to as the one described in https://technet.microsoft.com/en-us/library/gg399137.aspx




4. Enter an MDX or DAX statement in the Specify a MDX Query step. Click on Validate to double check that the query.



Once the data is imported, you can enrich the data model within PowerPivot as necessary for GeoFlow.

5. Jump back to Excel 2013 and click on Insert > GeoFlow to create a new tour based on the PowerPivot model. 

Below is a screenshot of GeoFlow working area based on data in PowerPivot sourced from a Tabular Model,with nearly 1 Million rows of data.

Wrap Up

In essence, because GeoFlow makes use of PowerPivot, it opens up the ability to use data from a wide variety of sources, including SQL Server and Tabular Model. Data must be imported and modelled in PowerPivot which is then exposed to GeoFlow.

GeoFlow and PowerPivot restrictions:

1. Can only use columns 
2. Supports relationship 

Further Reading / Research

"Getting Started with GeoFlow Preview" document is available for download here. 

GeoFlow Preview for Excel 2013 is available for download from here.

GeoFlow Reviews at MsSQLGirl.com

From Impaired to Insightful: Analysis with Geospatial Data session at PASS Summit 2013 (Oct 15 - 18, 2013)

Special thanks to NetIndex.com for providing ISP Daily Speed Data.

Each section below will look at the mechanism changes , starting off with the current state mechanism in the light-touch mode.

Mechanism So Far (Default)

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:
   
   
   
 Figure
1.1 – MDT Wizard Welcome Screen

• Requires Keyboard Layout drop-down selection
• Manual network configuration if accessing from a different subnet
• Manual acceptance to start the Deployment Wizard

Figure 1.2 – User Credentials

• Enter Username, password and the domain that the user credentials belong to

 Figure 1.3 – Task Sequence

• Choose the Task Sequence that you will use to build your machine

 These are some of the windows you would see when building a machine, as well as a few others that are related

• Computer Details
• Move Data and Settings
• User Data (Restore)
• Locale and Time
• Applications

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.

How to Achieve the Real ZTI Experience (Practical)

Custom.INI Settings

Let’s dive into the rules and Bootstrap.ini of our MDT environment:        

1. In the MDT Console, right click where it says “MDT Deployment Share,” and select Properties
2. Select the rules tab

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:

• UserDomain – The Doman which the account used to authenticate
  belongs to
• UserID – The username of the account which has permissions to
  authenticate
• UserPassword – Password of the account

So it should now look like this:

Figure 2.3 – Bootstrap.ini. Admin password blanked out for security reasons

Mechanism So Far (After Custom.ini settings applied)

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.

Task Sequences

 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

• Windows 7
• Windows 8
• Windows Server 2008 R2 (one with Server Role setups, and one without)
• Windows Server 2012 (One with Server Role Setup,s and one without)
• Company Standard Build

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

Applications

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

Mechanism so Far (After Configuring Task Sequences)

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.

Database Setup

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.

1.  In the MDT Deployment console, click the arrow next to the Advanced Configuration
2. Right click the Database folder and choose
3. Enter the details for your SQL Server from Server name. Instance and port number are optional but are helpful if your server does not adhere to default configuration. Network library should use TCP/IP Sockets
4.  Create a database by providing a name. In this case I have simply named this as MDT
5.  Enter a name for your SQL Server Share. In my case I have used DeploymentShare$
6.  Finish the wizard

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:

• Computers
• Roles
• Locations
• Make and Model

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.

Computer Rules

Figure 4.2

Location Rules

Figure 4.3

Make/Model Rules

Figure 4.4

Role Options

 Figure 4.5

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 studio
3. Go to Security – Logins. Then right click and choose New Login
4. 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 database
5. Click the Server roles tab and choose sysadmin role and click OK to finish
6. 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 added
into the WDS Server again.

To do this, open your WDS console and perform the following

1. Go to the boot images folder and highlight your boot image and choose the “Replace Image” option
2. Browse to the location of your deployment share, which would be C:\DeploymentShare\Boot\, and choose the x86 or x64 version
3.  Complete the wizard

Database Form

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:

• Asset Tag
• UUID
• Serial Number
• MAC Address

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:

• Task Sequence ID
• ComputerName
• JoinDomain
• DomainAdminName
• DomadinAdminDomain
• DomainAdminPassword
• Admin Password
• Applications

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.  

Mechanism so Far (After Database Configuration)

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: https://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.

 Administration List

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 Language

Value – Value Locale ID. These can be obtained from here https://msdn.microsoft.com/en-gb/goglobal/bb895996.aspx

OS 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 Role

Value – Role Name in PowerShell context. Can be found using this https://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 Feature

Value – OS Feature Name in PowerShell context. Can be found using this https://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 Services

Value - OS Role Service Name in PowerShell context. Can be found using this https://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

• Operating System – Task Sequence ID
• Local Administrator
  Password – AdminPassword
• MAC Address – OSDAdapter0MacAddress
• IP Address – OSDAdapter0IPAddressList
• Subnet Mask – OSDAdapter0SubnetMask
• Default Gateway – OSDAdapter0Gateways
• Keyboard Language – InputLocale
• System Locale – SystemLocale
• TimeZone – TimeZoneName

 The next form will be the Network Details, which provides fields used to join the domain:

• Join Domain Name – JoinDomain
• Domain Admin Name – DomainAdmin
• Domain Admin Password – DomainAdminPassword
• Domain Admin Domain – DomainAdminDomain

The next form will be Additional Roles, where you will choose your Roles/Role Services and OS Features if required:

• OS Roles
• OS Role Services
• OS Features

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:

• Machine Details
• Network Details
• Additional Roles

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:

• Machine Details
• Network Details
• Additional Roles
• ADDS Settings
• DHCP Settings
• DNS Settings

Administration – Users

Add users here from your domain to control access to the MDT Web Front end.

Administration – Access Roles

Here 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.)

Administration – Applications

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:

• Asset Tag
• UUID
• Serial Number
• MAC Address

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)

Applications

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.

Mechanism Now (after MDT Web Front End)

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. 

Mechanism All Together

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.

Administrative Drawback

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 so
there are two options:

Workaround 1

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.

Workaround 2

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

1. Enter the name for your machine, and Device ID will be the MAC Address. (Note: MAC Address 8 bit characters should be separated with “-“ and not “:”)
2. Click next if you are happy with defaults if the WDS and boot image is set as defaults. If not, please specify them in this step and click next
3. Skip the next window
4. Click to finish unless you wish to specify a user for your pre-staged machine

Conclusion

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.

I, a security engineer, was able to design out the system and configure it for use with our remote access solution.  Then I was able to document and define a process for the help desk to add and manage users. Users can also manage certain things about themselves via the web portal. Agents were also installed in our disaster recovery site, so if the main data center is down for whatever reason, those agents will answer the queries. Shortly, we will be putting other resources behind PhoneFactor.

One of the biggest questions we received from the user population was, “What if I don't have my phone, or I am in a place where I don't get cellular phone reception?” Well, the answer to that is simple. We taught the users how to go through the user web portal to perform a one-time bypass. We installed and configured the
web portal so users can change their phone number, add a phone number, and for one-time bypass they can answer their secret questions from there. So, users relaxed about not having access on airplanes, in remote wilderness places, or in  foreign countries if they choose not to incur roaming costs.

 From a support perspective, we leverage the PhoneFactor logs to troubleshoot access problems, to verify when someone connects, and to get various other details. We also get daily reports on usage that help us troubleshoot things and forecast usage in the case of a disaster or a snow day. We have three offices in the
upper mid-west, so we do have snow days.

Microsoft support has been excellent, as well. We found it sufficient to get gold support. They have helped in a timely manner with questions of a theoretical nature, as well as with more practical questions, stepping us through configuring applications or other minor user problems.

In short, PhoneFactor met all of our needs. Users like it and are now used to it. Best of all, we have met the goals of having a second factor of authentication.

This is part 2 of my blog, "OS Deployment: System Center Configuration Manager 2012, or Microsoft Deployment Toolkit, or Both," https://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? Inthis part, I will do a short (if you can call it that) analysis of the architecture of both System Center Configuration Manager and Microsoft Deployment Toolkit (MDT) deployments, so we can pick out features which we can use for the Zero Touch Installation (ZTI), as well as identify spots in which the ZTI can improve or help towards a parti

Why ZTI for Task Sequence Deployment

Whilst this ZTI method is based around the MDT side of things, I thought to base the reasoning around the SCCM side, MDT will also be explained. One thing SCCM might not necessarily focus on is the individuality of each machine. For example, the SCCM and MDT Task sequences would handle values which would be considered to set the machines individuality by providing randomized values for the following:

• Computer Name (Can be done through “Import Single Computer”)
• Network Details (IP Address, DNS, Default Gateway)
• Server Roles/Features
• Applications

Now these values can be set to your standards if you were to have conditions for naming to read from the Active Directory, and Network details if you have DHCP set appropriately.The point is that for a Task Sequence to consistently maintain your standards, it would rely on too many factors. It would be great to have this setup, but one thing you may not anticipate is when errors occur in this Task Sequence,  which would be a very tough task to troubleshoot due to its complications and multiple dependencies. Of course if this Administrative effort isn’t an issue for you, then perhaps this would be the way to go, But let’s take a MDT type solution, which is where ZTI will come into play

ZTI

The whole idea of ZTI is to provide Zero Touch. I have been skeptical towards this type of approach as it makes it harder to trace errors, as well as making you unable to have overall control over the whole build life cycle. But this can be done, and the administrative effort can be a lot shorter than it would with SCCM. So
let’s look at each Task Sequence so we can analyze and then take an element of each. this will allow us to cook up an overall solution and combine the best of both worlds.

SCCM Task Sequence

Once a machine has PXE booted into the distribution point, depending on your setup it may ask you for a PXE password. If not it will just ask for you to click “Next,” and you will see the Task Sequences available to you. Of course this can be avoided if you deploy the Task Sequence as “Required” which will have a countdown of 15 minutes before it automatically builds.

To focus on the individuality of each machine, it can either be automatically configured through the Task Sequence, or it would have to prompt at particular steps for this. But this would pause deployment, which would defeat the whole objective of ZTI.

One thing we could use from this is how it doesn't ask for any additional info by default,t such as how a MDT Task Sequence would do. This would be the foundation of how we want pre-staged machines to be. But with the individual focus already applied during this form of deployment, MDT Task Sequence, this is more focused on two physical boot images listed within the PXE boot and  will lead you right into the MDT build process. This will then display a Wizard for you to specify your settings, and this Is great as you get to have your input on exactly how this machine is built.

However, in terms of ZTI, this is considered to be light touch as you still have to manually input the information in order for the deployment to start. But here we still do take a dose of its actions. As we can see from its steps, vital information is needed, and this is what we to provide but in a more seamless manner.

SCCM + MDT Integrated Task Sequence

A MDT task sequence via SCCM gives you best  both worlds as you can now use advancements and settings within MDT, which may not be available through SCCM. For example the biggest one would be the Wizard function. With this, you can now go through each window to specify settings to customize the machine you are looking to build, and can also create a custom deployment wizard to pre-define how it creates these settings.

Again, these advancements within the custom wizard to pre-define and set default variables aid in the assistance of standardizing how you build the machines with its individual focus. This is something we would like to use also.

How to achieve a real ZTI experience (Theoretical Design)

Within the MDT 2012 toolkit console you have several options which would build the architecture for this

1)     Custom.ini Settings

Function: Here you can specify the steps in which you would want to skip in the default wizard of MDT booting into the PXE, as we will be using a different method of selecting TaskSequences.

Reason: So the aim of this step is so once every step in the wizard is silenced, it would allow us to customize the experience of how we would build machines with a ZTI focus. Once they are pre-staged, there will be no manual input required by the users

2)     Task Sequences

Function: For these task sequences to aid in the ZTI focus, we can either do Task Sequences, which would perhaps deploy either a vanilla OS build (Thin) or an image that has a Company Standard focus with apps and settings pre-loaded (Thick).But what we can do is add steps into these Task Sequences such as “New Application” and “Install Role or Features” etc.

Reason: This will be so while pre-staging. We can also pre-stage various options such as to install another application on top, whether Thin or Thick build, a new role or feature, etc.. The overall reason is to add further customization to the builds is to focus more on role based identities and having to cut administrative effort on post build related tasks.

3)     Database

Function: Setting up the database within the console will allow you open up to the pre-staging of building machines and create rules and specify the order in which these rules are followed.

Reason: In order to focus on the individuality of each machine, regardless of Task Sequence used, we need its database properties, as well as the detection of the machine to the database

4)     MDT Deployment Frontend
(Optional but recommended)

Function: A great add-on created by Maik Koster can be found here https://mdtwebfrontend.codeplex.com. In the Database of MDT, there is a section in where you would pre-stage machines with many settings and variables. Though it will still have ZTI working fully, it lacks in User Experience and feasibility, and this is where
the MDT Deployment Frontend comes in. With this powerful tool it adds a Webpage, which ties into the MDT database to use the same settings and variables, but it can be customized for better quality control and better focus on the user experience.

Reason: A little direction on the setup to tie into the ZTI focus can make the administrative effort very painless and efficient, and make  the interpretation of advanced settings very easy. For overall control of customization I highly recommend this.

5)     Specific Features from
MDT & SCCM

Earlier in the ZTI section, I went through the SCCM and MDT deployment breakdown and picked particular features that the ZTI would be based around.

SCCM for its ability to go straight into a Task Sequence without no user input

MDT for displaying the settings we can customize in order to build the machine with manual input

SCCM + MDT for providing the advancements of the settings within a wizard to predefine values and variables

Reason: These are the foundation points to build the user experience and feasibility within the MDT Deployment Frontend so all features will be used to provide the flow of the lifecycle, as well as reduce concerns of overall administrative effort.

Overall these are the building blocks to work smarter, and not harder.

I hope this part of my series was helpful. The next and final part will show visually the steps and breakdown on how this design will come together, and it outline real-world scenarios in which this can be applied to a particular way of carrying out tasks.

Organisations always don’t tend to have the same type of requirements where that comes to migration, upgrades, and infrastructure-type additions. And also understanding the requirements of the business is one thing, but having a more in-depth scenario-based understanding of what each can do in different bespoke situations can make all the difference

Overview

So we have two Microsoft products, SCCM 2012 & MDT. One of the common denominators of these is the Windows Deployment Services (WDS) role, which lets you use image files (standard is .wim) to build bare metal machines and also provides devices with ways to connect to the server over the network being Pre-Execution environment (PXE) and a discover image, which can connect clients that cannot PXE boot to the server.

Without going into a great deal of WDS—though it’s tempting J—it provides a great capability to build machines. However, in the long run, many situations challenge how WDS would fit into your plan of a default mechanism for OS deployment.

For example, WDS isn’t a process you would use for a migration to a different OS. Though it can do this, the process isn’t seamless and leaves you to perform all of the work to make this happen

You do have the option of answer files which can control and structure how the OS will be configured after the out of box environment (OOBE) and pre-stage its boot selection, which is a great way of aiming towards the “ZTI” approach, but you’ll find with WDS as with a few technologies it does take a good amount of administrative effort, which you may or may not be motivated to do on a regular basis, and with the more advanced outer shells such as MDT or SCCM, the idea is to work smarter and not harder

System Centre Configuration Manager 2012 (OS Deployment)

We are all familiar with how SCCM works in its approach to deployment, but I think its strengths apply more around the lifecycle of how it performs, controls and maintains the deployment

For example, the security focus is great, as you can use a password to “lock” the deployment to only administrators who would know of the password. This would stop machines from being rebuilt in error.

You can control pre-staging machines outside of WDS and perform Task Sequence deployments to collections of specific machines, as well as all unknown machines that the SCCM infrastructure does not recognize.

The various monitors and logs help you pinpoint where a deployment would have failed and the scheduling of its availability.

These are a few of many points as to why SCCM is a fan favourite of deployment—not only the features of OS deployment but the lifecycle of it and the security pre-staged focus behind it.

I feel the only little drawback is that in smaller environments, a component such as SCCM could be perhaps too much to configure. I believe the minimum amount of devices would be at least 500, but since there is a lot of room for customization and advancements that you can make, the administrative effort can also hugely increase. With a smaller environment that could impact speed as well as quality of service thus making troubleshooting scenarios more of a nightmare. It just doesn’t seem to work as well if you are only using the fundamental basics of its deployment features, and you tend to get the best out of SCCM when there is a design involved into how it will fit the business.

 Microsoft Deployment Toolkit (MDT)

This is a free tool for OS deployment. But I feel sometimes we can underestimate what a free tool can actually do compared to a powerhouse such as SCCM.

Similarities in comparison to SCCM are that they both initiate deployment via task sequences, which contain OS and application deployment, as well as the ability to capture customized wim images for standardised building. But what I really want to do is drill more into the Zero Touch Interface (ZTI) side of things.

ZTI implies automated deployment that would require no touch. This is something MDT can do extremely well, with its slight steps of administrative effort.

And with me knowing how powerful SCCM is, what if we could make MDT into the same powerhouse? I actually have been able to do so in a few situations and will go more into its setup with comments to show you how it will all fit together later.

Now compared to SCCM, MDT’s lifecycle and security focus are not as heavy. Although it can be built up to SCCM’s level, one feature that can be unlocked is its quickness, as well as enhancements that can be channelled more in a simpler way. However, I probably wouldn’t recommend MDT’s use within a larger environment. This is where SCCM really shine. But again, MDT can be unlocked to fit in a large environment with the right design, and it all comes from analysing the business needs and goals in order to come up with the best fitting solution.

I’ll follow this article with more details, so please let me know what you think and what questions you have.