As soon as you press Enter a confirmation dialog opens informing us that the iSCSI Initiator service needs to be started. Press Yes to start the service and put it in Automatic mode, so every time the server boots up the iSCSI service starts too.

Now we get the iSCSI Initiator Properties where we can type the FQDN, NetBIOS or IP address of the iSCSI Target.

Let’s add a target and see how it works. I will add a 50 GB drive on my Server Core trough iSCSI. I the target box I will type the name of my iSCSI Target and click the Quick Connect button.

Now if we use a remote Server Manager console we can see the new drive, and we can format it just like a SCSI or SAS drive.

To begin open the Exchange Management Console, expand Server Configuration and click the Client Access object. In the Actions pane click the link Enable Outlook Anywhere.

Type your external host name and choose the authentication method. The external host name needs to be present in the Exchange certificate installed on the server, or the connection will not be trusted and users get very aggravated by those certificates error messages. If you are publishing Outlook Anywhere for users that are not part of the domain is best to use Basic Authentication. NTLM is for users that are domain members. Check Allow secure channel (SSL) offloading, only if you have hardware load balancer for those CAS servers. In this example I am using only one CAS server, so I will let this check box as it is. Click the Enable button.

After the wizard is done, a warning message is displayed telling us that Outlook Anywhere configuration will be available within a period of approximately fifteen minutes.

You can do all this using the Exchange Management Shell too:

Enable-OutlookAnywhere -Server 'Ex2010.vkernel.local' -ExternalHostname 'external.vkernel.ro' -DefaultAuthenticationMethod 'Basic' -SSLOffloading $false

Now if you open an Outlook client, you should be able to connect, off course if your firewall is properly set up.

As soon as the wizard loads, you will be notified about an earlier version of vCenter Server installed on the server. Click Next to continue.

On the End User Patent Agreement page click Next.

Accept the EULA and continue.

Complete the boxes on the Customer Information page. You don’t have to put the license key right now, you can also license vCenter Server after the installation is complete.

If you don’t enter a license key now a warning box appears informing us that the previous license, in our case the vCenter 4.1 license, is not valid for this version. Just click YES to continue.

Because I am using Integrated Windows Authentication, the connection to the SQL server is done using the logged on user, which is a domain admin user account. If you are using SQL authentication provide the database user name and password and click Next.

Here select the first option Upgrade vCenter Server database then check the box to confirm that you backed up the database and the SSL certificates.

For the sake of this example I will choose Automatic and let the wizard upgrade all the vCenter Agents on all ESX hosts connected to this vCenter instance.

Provide the password for the service account that vCenter service will run under, and click Next to continue.

As you can see the vCenter Server installation path cannot be changed, so the only path that you can change is the Inventory Service.

Leave the default ports and click Next.

The same here, leave the defaults and continue.

Here choose the Inventory Size that corresponds to your environment. For this example I will go with the first option.

At the last wizard screen click the Install button to start upgrading the vCenter server.

If everything went well, you will be notified at the end of the installation with a successful screen. Click Finish to close the wizard.

Now open the vSphere client and connect to the vCenter server.

As soon as you click the Login button the update window appears to upgrade the vSphere client to version 5. Click Run the Installer button, to start downloading the necessary files for the upgrade.

Don’t be scared about the message after the download is completed, just click OK. Is just telling you that all the necessary files for the upgrade were saved on a temporary folder.

At the first screen of the vSphere Client wizard click Next twice to skip the Welcome screen and the End-User Patent Agreement screen.

Accept the EULA and continue.

Complete the Customer Information and click Next.

At the Ready to Install the Program screen click the Install button.

Click Finish at the end of the installation.

Now connect to your vCenter server and see if everything is how is supposed to be. All ESX hosts should be connected to the infrastructure and their agents upgraded.

Before we go to Amsterdam (I don’t know, I just like the name) we need to create and configure sites by opening Active Directory Sites and Services from Administrative Tools. Right-click the Sites folder and choose New Site.

In the Name box type the name of the new site, which is Amsterdam in this example, then select the DEFAULTIPSITELINK and click OK.

An information screen pops-up telling us that we need to add a subnet to the site we just created. Click OK, because this was my next step anyway.

Right-click the Subnets folder and choose New Subnet.

In the Prefix box type the subnet for the branch office then select a site object for this prefix. In this case the subnet for the branch office is 192.168.100.0/24 and the site object is Amsterdam.

Now let’s take care of the main office site too. Right-click the Default-First-Site-Name and choose Rename. Give it a name that represents the main office location, and in this case is Cluj-Napoca.

Go to the Subnets folder again, right-click the folder and choose New Subnet. In the Prefix box type the subnet for the main office, then select the site object.

Now your Active Directory Sites and Services should look like this.

On the branch office server configure the IP’s. Of course in the DNS box you need to put the IP address of the Domain Controller in the main office so we can find the domain.

I assume you have a proper VPN connection between the two locations, and both servers can communicate. Now we can start creating the child domain in the branch office. Do a Start > Run > dcpromo and click OK.

After the binaries are installed the Active Directory Domain Services Installation Wizard appears. Check the Use Advanced mode installation box and click Next.

In Windows Server 2008 and 2008 R2 a new security setting was implemented and older clients may be affected. This is what the Operating System Compatibility page is telling us, but is not our case since we have only 2008 R2 operating systems. Click Next to continue.

On the Deployment Configuration page choose Existing Forest > Create a new domain in an existing forest. Do NOT check the box Create a new domain tree instead of a new child domain, because we are not creating the child domain in a separate tree.

Type the domain name in the main office, then provide the proper credentials to connect to the domain. The user account must be a member of the Domain Admins group or the Enterprise Admins group.

In the fist box click the Browse button to select the parent domain. In the second box type the name of your child domain, and in this example is Amsterdam.

Leave the defaults here and click Next to continue.

If you have the intention of creating additional domain controllers in this domain (amsterdam.vkernel.local) with older operating systems (2000-2003), leave the domain functional level at 2000 or 2003. Since we have only Windows 2008 R2 we can set the domain functional level at Windows Server 2008 R2.

As you can see the site, the correct site was automatically selected based on the subnet we created earlier. If the wizard selected the wrong site, uncheck the box Use the site that corresponds to the IP address of this computer, and select the proper site from the list. Never had to do that; you will only have to do it if you do not configure Active Directory Sites and Services correctly.

Check the Global Catalog box here, so we have faster searches for objects in AD. More information about Global Catalog servers can be found here.

Select the replication partner in the other domain. If you have multiple Domain Controllers in the main office you should set only one of them to be the replication partner with the one in the branch office.

Here you can change the Active Directory database and logs location, if you don’t like the default one.

Type a password for the Active Directory Restore Mode then click Next.

Review your selections on the Summary screen, and if everything it’s OK click Next button to start creating the child domain.

If during the Active Directory Domain Services installation process you get the error The operation failed because: Active Directory Domain Services could not replicate the directory partition… “Could not find the domain controller for this domain”, join the server to the domain, reboot then resume the dcpromo operation.

After the domain controller reboots, login using the Administrator account. You will be asked to change the password, and you will need to provide a complex password to be able to continue.

Now if you open Active Directory Sites and Services you can see the new domain controller created in the Amsterdam site.

As software requirements it goes like this:

For more details about system requirements please visit this website. For this lab I will use a Windows Server 2008 R2 SP1 for the VMM server, as for the database I will user SQL Server 2008 R2 Enterprise. Everything is in a domain environment, and all VMM roles will be installed on the same box. If you don’t meet all the prerequisites, installation will not continue and the wizard will notify you which are the missing ones.

As a first step install .NET Framework 3.5 by opening Server Manager, right-click Features and choose Add Features.

Check the box next to .Net Framework 3.5.1 and click Next then Install.

If you don’t have the Windows AIK kit for Windows 7 and 2008 server, go to this website and download it. Now mount the ISO (because you are using virtualization, right ?) and on the splash screen click the Windows AIK Setup link. Follow the wizard and use the default settings.

After you are done with Window AIK is time to install IIS for the Self Service Portal. Open Server Manager, right-click Roles and choose Add Roles.

Check the box next to Web Server (IIS) and click Next. One the Role Services page check the following boxes: .NET Extensibility, ASP.NET, Default Document, Directory Browsing, HTTP Errors, IIS 6 Metabase Compatibility, IIS 6 WMI Compatibility, ISAPI Extensions, ISAPI, Filters, Request Filtering, Static Content. Click Next then Install.

The SQL Server 2008 R2 Command Line Utilities must be installed, so mount the SQL server 2008 R2 DVD, click Installation then New Installation or add features to an existing installation. Or go to Microsoft’s page and download the Command Lines Utilities from there, if you can’t find the SQL server ISO or DVD.

When you get to the SQL Feature Selection screen check Management Tools – Basic box and click Next to continue.

Is time to install SCVMM; mount the SCVMM DVD and on the initial screen click Install.

After the wizard launches select all three features check boxes and click Next.

Provide product registration information and continue the wizard.

Accept the EULA and click Next.

Right now I don’t want to participate on the CEIP program, so I will choose No, I am not willing to participate.

Choose the location where all the components will be installed then click Next to continue.

The wizard will start checking if all the requirements are met.

Now is time to tell the wizard the name, the instance and other information about our SQL server. In the Server name box type the name of the SQL server. In the Port box type the port name you are using to connect to the SQL server. If you are using the default port, like I am in this example, you can leave the box empty. The same goes for the Instance Name, if you are using the default one you can leave the box empty. I am not going to type a user name and password here, because I am logged in with a domain admin account, and the wizard is using the current log on credentials to connect to the SQL server. If you want to you can use a different domain account to connect to the SQL server and create the database. The last option is to create a new database on the SQL server or use an existing one; in this case we are creating a new database.

A very important thing to remember is that the SQL service needs to run under domain credentials or you will get this error when trying to connect to the VMM service.

On the Configure service account and distributed key management click the Select button and type the account that is going to be used for the VMM service. Because I don’t like my services to run under the default Administrator account, I created a separate account in AD for this. Don’t check the box Store my keys in Active Directory, because we are going to store them on the local machine.

Here leave the default ports and click Next to continue.

Since the Self-Service portal is running on this server, just type the local server name in the box. Leave the ports alone and click Next.

Choose where to store the VMM library, if the default path is not good for you.

On the Summary screen click the Install button to start the installation.

At the end click the Close button to launch the VMM Console.

Because I want to connect to this address/server every time I open the console, I checked the box Automatically connect with this settings.

Now we can start adding hosts and create virtual machines using the VMM console;

and by using the Self-Service portal your users can benefit from the virtualization technology by running their own virtual machines.

To log in to the Self-Service portal you need to create a User Role, by selecting Settings > Create User Role from the VMM console.

First you need to know what’s the name of the role you want to install, and for that use the oclist command.

As you can see the list is huge and you can’t see all the roles names in the console window, even if you scroll the bar up to the top. This is the reason why I like to export all the roles names to a text file on the local machine by issuing the following command:

oclist > c:\roles.txt

If you open the file you can see all the role names.

Now that you know how to list all the roles is time to install some of them by using the ocsetup command. With the command typed bellow we are installing the IIS role. The bad news is that you don’t know when a role is finished installing since no progress bar appears during installation.

ocsetup IIS-WebServerRole

Let’s install another role, for example Hyper-V, since is so popular.

ocsetup  Microsoft-Hyper-V

Click Yes to reboot the server.

Now if you do the oclist command again you can see on the left side it says the role is installed.

Installing a role in server core is very easy, all you have to know is the actual name of the role. This is easy to, because you know now how to export those names in a text file and read the names from there.

For this guide I have a TMG 2010 server, a VMware vShpere Web Client Server and a Domain Controller. Off course, all servers are joined to the domain. The certificate used here is a SAN certificate and is issued by an Internal Enterprise Root CA, and all my external clients have the root CA certificate installed in the certificates store. In a real production environment I recommend you purchase a commercial CA. Before we start I presume you already created an A or CNAME record on your public DNS server which points to the external IP address of your TMG server.

First we need to take care of the VMware vSphere Web Client Server certificate, by replacing the default one with the one issued by our internal CA. Since I already have a guide for this at this link, I’m not going to review it here. Read the post, replace the default certificate, then come back here and continue reading. After the certificate is in place on the vSphere Web Client Server, we need to copy the rui.pfx certificate on the TMG server. Here (on the TMG server) open the Certificates Store (Start > Run > certmgr.msc) and import the certificate in the Personal Local Computer folder. Right click the Personal folder and choose All Tasks > Import. Follow the wizard.

When you get to the password screen type the certificate password which is testpassword. This password is valid only if you followed along my post for replacing the VMware vSphere 5 Web Client Server certificate.

After you finish the wizard, you can see the certificate in the Certificates Store with its private key.

Now let’s publish the site with TMG 2010. Click the Firewall object, then in the Tasks pane click the link Publish Web Sites.

Give the rule a name, then click Next to continue.

We need to allow the traffic since we want to publish this rule to the internet, so just leave the defaults here and continue.

Since we publish only one web site the first option is perfect.

The vShpere Web Client Server site is using SSL, so we are going to use the first option here too.

Because I like my internal site names to be the same as the external ones (it doesn’t confuse the users), I will type here the external name I will use to connect to the vSphere site. Check the box Use a computer name or IP address to connect to the published server, then bellow type the name of the server.

Here put  /* to publish the whole website.

On the Public name box type the public name users/admins are using in their browsers to connect to the site. The public name needs to exist in the certificate (imported on the TMG server) SAN attribute or the Common Name.

Now we need to create a new listener, so TMG will process the HTTPS traffic matching the FQDN we put in the certificate. Click the New button to start creating the listener.

Give the listener a name and continue the wizard.

Here go with the default setting, because we are publishing a secure website.

Select External, so TMG 2010 will listen on traffic coming on the external interface.

Now is time to get use of that certificate. Click the Select Certificate button, then in the list select the certificate and hit Select.

We now have a listener SSL certificate. Click Next to continue.

Here select No Authentication, because we don’t want TMG to authenticate the external clients, we want vShere Web Client Server to authenticate them.

SSO is disabled, so click Next to go forward.

On the Summary screen click Finish to create the listener.

Back on the Publishing Rule Wizard, select the new listener and click Next to continue.

Select No delegation, but client may authenticate directly.

On the User Sets page leave All Users, meaning we want everyone to be able to connect to the web site.

On the Summary screen click Finish to create the rule.

Don’t hit the Apply button yet on the TMG server, because we need to do some modifications on this rule. Right-click the rule and choose Properties.

Go to the Bridging tab and in the Redirect requests to the SSL port box, type 9443.

The same change needs to be done on the Listener tab. Click Properties, go to connections and type 9443 on the Enable SSL (HTTPS) connections on port box.

Click OK and close all the windows, and now you can Apply the changes on the TMG server, by clicking the Apply button.

Go to one of your external clients and connect to the web site by typing https://server FQDN:9443/vsphere-client. As you can see I have an internal domain (vkernel.local) but I’m using the external domain name to connect, and is working just fine.

To begin open the VMM console and on the Actions pane click the link Add VMware VirtualCenter server.

In the Computer Name box type the name of the Virtual Center server you want to manage with VMM, then provide the credentials to connect to the server. Leave the option Communicate with VMware ESX Server hosts in secure mode enabled.

If your vCenter certificate is not trusted you will receive a certificate warning; just click Import, and ignore the warning. If you want to know how to issue a certificate for a VMware vCenter server follow this guide.

As soon as the vCenter server is added, the VMM service automatically starts discovering ESX hosts, virtual machines and other resources that are part of that VMware vCenter infrastructure. What you can also see, is that those ESX hosts are working in limited mode.

To fix this right-click on one of the ESX hosts and choose Configure Security.

Type the user name and password to connect to the ESX host, then click the Retrieve button, so the VMM service can accept the ESX host certificate.

After the certificate is retrieved from the ESX host check the box Accept both the certificate and public key for this host, then click OK. Repeat this operation for the rest of the ESX hosts, that you have in your environment.

Now those ESX hosts should have an OK status in the VMM console, meaning they are working in full mode.

In this guide I’m going to show you how to manage Hyper-V running on Server Core from a remote console that sits on a Windows 7 machine. All machines in this lab are joined to the domain, so everything will be easy. As a first step we need to install the Remote administration kit for Windows 7; download it from here and run the installer. When the installation is done you might expect to see the Hyper-V console in Administrative Tools, but is not. We need to add it from Programs and Features in Control Panel. Once here click the link Turn Windows features on or off. On the Windows Features screen expand Remote Server Administration Tools > Remote Administration Tools and check the Hyper-V Tools box then click OK.

Now if you look in Administrative Tools you can see the Hyper-V Manager. Open it, and try to connect to one of the Hyper-V servers, by right clicking the Hyper-V Manager and select Connect to Server.

Type the name of your Hyper-V server and click OK.

Looks like it can connect just fine. Now go ahead and create some virtual machines .

I will use the latest WSUS version at this time, which is 3.0 with SP2 installed on Windows Server 2008 R2 SP1 using SQL server 2005 Express. The WSUS database will be migrated to a SQL server 2008 Enterprise which is also installed on a Windows Server 2008 R2 SP1 box. All machines are part of a domain. Let’s begin.

First we need to detach the WSUS database to be able to copy it on the dedicated SQL server. For this operation we are going to use SQL Server Management Studio Express 2005. Download the installation kit from here, then install it on the WSUS server. When you’re done, open the management console and connect to this instance \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query. Click Connect.

Expand the Databases folder, right-click the WSUS database (SUSDB), go to Tasks and click Detach.

On the Detach Database window check the box under Drop Connections, then click OK to detach the database.

Now your WSUS database should not be present any more under the Databases folder.

Copy the WSUS database and log files to a preferred location on the dedicated SQL server machine.

On the SQL 2008 server open the SQL Management Studio and connect to your instance. In this example I used a default instance.

Expand the Databases folder, right-click and choose Attach.

Click the Add button and locate the two files you copied from the WSUS server (SUSDB.mdf and SUSDB_log.ldf). Select the .mdf file and click OK.

In the Attach Databases window select the SUSDB_log.ldf file then click the Remove button.

Now you can click OK to attach the database.

Don’t close the Management Studio, because we need to give the WSUS server permissions to this database. Expand the Security folder, right-click Logins and choose New Login.

Here we need to add the WSUS computer account, but that Search button is useless for this operation. On the Login name box type your WSUS computer name in the form domain\WSUSComputer$. In my case is vkernel\Server-WSUS$. On the Default database choose the WSUS database.

On the left click the User Mapping option. Check the box next to the WSUS database, and on the Database role membership check the webService box. Now you can click OK.

Now the WSUS server has rights to connect to this SQL server instance.

We are almost done. All we need to do now is point the WSUS server to use the new SQL server instance. Go back to the WSUS server and open the registry editor (Start > Run > regedit). Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup. Here we need to change three keys:

SqlServerName – put the new name of your SQL server and instance (server\instance). If you are using the default instance, like I am, the server name will suffice.

wYukonInstalled – set to 0 (zero)

SqlInstanceIsRemote – set to 1 (one)

Restart the Update Services and World Wide Web Publishing Service services, either by using the terminal or the Services console.

On the WSUS Management Console click the Reset Server Node button.

Now everything should be back to normal.

A single vCenter can manage 300 ESX host with 3000 virtual machines, but using linked mode can manage 1000 ESX hosts with 10000 virtual machines. As you can see having a single management console for multiple vCenter servers is not the only reason to linked them together. However, to do this you need to have the proper license, because is not going to work with Foundation or Essential Edition. More information about the Linked Mode prerequisites can be found here. Before I start I need to mention one more thing, I you have multiple forests or domains in your environment, trust needs to be created between them.

For this lab I have three VMware vCenter 5 servers that are all part of a single domain, and all traffic is allowed between the servers. To start on one of the vCenter servers open the linked mode configuration wizard from Start > All Programs > VMware > vCenter Server Linked Mode Configuration.

The VMware vCenter wizard will appear. Click Next to skip the Welcome screen and continue.

Since we want to link our vCenter servers, we are going with the default option here which is Modify linked mode configuration.

Again we are going with the default selection here, so click Next to continue.

A warning is displayed telling us that older versions of vCenter servers are not supported. We can only link version 5  or later servers in this configuration.

In the server box, type the FQDN of the remote vCenter server and click Next. Leave the default port, but make sure that your firewall permits traffic on this port.

To start configuring the link just click Continue.

At the end you will be notified if the installation succeeded. Click Finish to close the wizard.

Open the vSphere client and connect to one of the linked vCenter servers. Now you can manage both servers using a single console. Great haaa.

Now let’s link a third vCenter server, by running the wizard again. Almost forgot, you need to do this from the vCenter server that is not linked. If you run the wizard from one of the already linked servers is not going to work; you will only have the option to isolate the server instance but not to join one, since those servers are already joined.

Log on to the third server and go to  Start > All Programs > VMware > vCenter Server Linked Mode Configuration. When you get to the point where you need to put the vCenter server FQDN address, you have two options here. You can type the address of the first vCenter server or the second one, it doesn’t matter. For the sake of this example I will type the address of my second vCenter server, because I typed the first one when I’ve made the first link.

After the link is done, open the vShpere Client and connect to any one of these three servers we just linked. And voilà…everything worked out just fine. We have our three vCenter in Linked Mode.

Before we move forward you need to know the prerequisites of DPM 2012, so here they are:

As you can see in the prerequisites DPM 2012 supports only SQL server 2008 R2, and you need to have Reporting Services configured too. For this lab I have a Domain Controller running 2008 R2 SP1, a SQL server 2008 R2 Enterprise, and a Windows 2008 R2 system where DPM 2012 will be installed. Before we start with the actual installation we need to prepare the SQL server for DPM, so mount the DPM ISO on the SQL server (you’re using virtualization, right ?) and browse to SCDPM > SQLPrepInstaller. Here execute SQLPrepinstaller_x64.exe.

Install the Visual C++ 2008 Redistributable package by following the wizard.

A message is displayed when the installation succeeded.

Before we go on, verify that the SQL service is running under a domain user account, and the SQL Agent is started and set as automatic start mode. In my example here I created a domain user account and all the SQL services are running under that account, which means the DPM installation should go smoothly.

If your SQL service is not running under a domain user account you will have an error message during the DPM prerequisites check.

After we configured the SQL server, we can start the DPM 2012 installation, so log on to the server and fire up the wizard. On the splash screen click the Data Protection Manager link. Wait a minute so the wizard prepares the installation of DPM.

Accept the EULA and click OK.

Click Next to skip the Welcome screen on the DPM 2012 installation wizard.

On the Prerequisites Check page choose the second option to use an existing instance of SQL server. Complete the boxes and click the Check and Install button.

After the prerequisites are installed a reboot is required, so go ahead and reboot the server then start the installation again. Follow the exact same installation steps as before.

Now that all the prerequisites are met, we can continue with the installation, so click Next.

Enter the product registration information and continue the wizard.

If you don’t want to install DPM on the C drive you can change the path by clicking the Change button. For this example the default path is just fine for me.

Provide a password for the local user account that DPM 2012 will create on the SQL server.

Select the option Use Microsoft Update when I check for updates, to patch the DPM product, then hit Next.

Since this is a lab environment I will choose not to participate on the CEIP program.

Click the Install button to start installing DPM 2012. This is going to take quite some time, so be patient.

After the installation is finished, you can launch the DPM 2012 Management Console from the desktop icon.

In the terminal type sconfig then press ENTER. The Server Configuration menu will appear. Right now the server is part of a workgroup, and to join it to a domain press 1 then ENTER. Type D for domain and press ENTER again.

Now type the domain name and hit ENTER, then provide the user that has the rights to join this server to the domain. I am using the domain admin account here.

As soon as you hit the ENTER key another window will pop-up to type the administrator password.

A message will be displayed giving us the option to change the computer name before restart. For me the server name is OK so I will just click NO.

Another message is displayed telling us that a restart is necessary for the changes to apply. Click Yes to restart now.

After restart we have the option to log on to the domain, and if you go in the Server Configuration menu you can see the domain name instead of the workgroup.

The computer account was also created in Active Directory.

Using the netdom command is something like this:

netdom join ComputerName /domain:DomainName /userd:UserName /passwordd:*

and in my case

netdom join 2k8core /domain:vkernel.local /userd:administrator /passwordd:*

Reboot the the server and you are good to go.

Easy haaa. My problem was that someone deleted the pending request, and left me with no option to associate the private key to the certificate. So…I taught I recreate the environment in my lab at home and start this post in case someone will encounter the same problem. The way I managed to solve this was by using the certutil command. So first things first…import the new certificate in the Certificates Store, either by using the mmc console or by using the certutil command. Just ignore the expiration date on the old certificate in the image bellow.

Now if you open the imported certificate you can see that it has no private key; meaning…is useless, for now.

Don’t close the certificate, instead go to the Details tab and at the button click the Thumbprint field; copy that thumbprint on the clipboard.

Now from a terminal issue the following command:

certutil -repairstore my "thumbprint"

where thumbprint is the tumbprint you just copied on the clipboard from the certificate Details tab. In my case is:

certutil -repairstore my "9f 05 01 58 3c 52 e7 28 bb ae 7d 11 06 98 09 fe d5 f8 d6 4f"

Open again the certificate from the Certificates Store, and as you can see now it has a private key associated. If you still don’t see the private key on the new certificate just hit F5 to refresh the Certificates Store.

Go in IIS and try to replace the old certificate with the new one. The new certificate appears in the list, because it has a private key.

Verify that is working. If you get the padlock icon you’re good to go. If you are still not convinced you can open the certificate from the browser and go to the Thumbprint field. The thumbprint should be identical with the thumbprint of the new certificate in the Certificates Store.

If your vSphere Web Client Server is accessed from the outside, I recommend you install a commercial certificate, or you’ll have to install the root certificate of your internal CA on every client that connects to the vSphere Web Client Server.

To test this I have a Domain Controller running Windows Server 2008 R2, and one vSphere 5 Web Client Server joined to the domain. To create the certificate private key I will use OpenSSL, so let’s start.

Open a terminal and go to the bin directory of OpenSSL, then type the following commands one at a time, and don’t set a challenge password at the end:

openssl genrsa 2048 > rui.key
openssl req -new -key rui.key > rui.csr

Complete the required information and be very careful at the Common Name line. You need to type the FQDN that you and your clients will use to connect to the management server. In this example I used the internal FQDN of the server, since I am not going to publish this on the internet.

If you want to, or if you have the budget, you can use SAN certificates; they work great, I tested them. That way you can include the NetBIOS name, internal FQDN name, and the external FQDN name of the server/site.

Now from your OpenSSL bin directory open with notepad or any other editor the rui.csr file and copy the request to your clipboard; be sure not to modify it in any way. On the internal CA Web page choose Request a certificate > advanced certificate request > Submit a certificate request by using a base-64-encoded… then paste the content (the request code from the rui.csr file) from your clipboard in the Saved Request box and choose Web Server from the Certificate Template. Click the Submit button.

Download the certificate using Base 64 encoded option, and name the certificate rui.cer. It’s easier in the next section if you name it like this.

Copy the certificate in the bin directory of OpenSSL, then issue the following commands:

openssl x509 -in rui.cer -out rui.crt
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Be careful, the password for the certificate (.pfx file) needs to be “testpassword” or is not going to work;  the vSphere Web Client service will stop. I struggled with this for hours, until I realized what the problem was.

Open Explorer and browse to C:\Program Files\VMware\Infrastructure\vSphere Web Client\DMServer\config\ssl\. Here you can see the default certificate and private key. Backup these files and paste those we created and located in the bin directory of OpenSSL. You need rui.key, rui.pfx, rui.crt.

Now open the Services console and restart the vSphere Web Client service, or use the command line:

net stop vspherewebclientsvc & net start vspherewebclientsvc

After the service is up and running again, connect to the vSphere Web Client Server using the address https:\\ServerFQDN:9443\vsphere-client. If you get the 400 Bad Request error just wait a couple of minutes, then refresh the browser.

Now it works, and the web site is trusted and secure.

To be able to keep up with the practice you need a Domain Controller, a Web server, and a client. If you don’t have the client is OK, you can test from the Domain Controller, but I want to make it as real as possible. Servers are all running Windows 2008 R2, and the client is running Windows 7. On the Domain Controller I’ve already installed the Active Directory Certificate Services role as Enterprise Root Certification Authority, and the Web server along with the client are joined to the domain. You need to have at least Internet Explorer 8 for this to work. Now that we have our lab in place, let’s start working, or for some of us…let’s have fun.

Open Certificates Templates mmc using Start > Run > certtmpl.msc. Search for the Web server template, right-click on it and choose Duplicate Template.

Here you can either use Windows Server 2003 Enterprise, to create version two certificates, or the second option to create a version three certificate. We are going with the second option, so check the radio button Windows Server 2008 Enterprise and click OK.

Type a name for the certificate and a validity period if you want to change the default one.

Go to the Extensions tab, and here click on the Issuance Policies extension, then hit the Edit button.

Since we don’t have any Issuance Policy we need to add one by clicking the Add button.

As you can see there are some default Issuance Policies already present, but we need to create a new one for our EV certificate to work. Click the New button.

Give the new Issuance Policy a name, and optional you can type a CPS location. CPS comes from Certificate Practice Statement and is a document that describes the organization’s security policy. At the end we have the OID (Object Identifier) which is very important; copy the OID because we need it later. Click OK when you’re done.

On the Add Issuance Policy window make sure that the new policy is selected, and click OK.

Now on the Issuance Policy description you should have something similar to mine.

Go to the Security tab, because we need to set the right permissions for the Web server to be able to request this type of certificate. Click the Add button.

On the object name list type the name of your Web server. Be sure on the Object Types the Computer object is selected.

Once the server is in the ACL (Access Control List) check the box to allow enrollment. Click OK to create the certificate.

Now we need to bind this template to the Certificate Templates on the Enterprise CA. Go to Administrative Tools > Certification Authority expand your Root CA, right-click Certificate Templates and choose New > Certificate Template to Issue.

From the list select the certificate we just created and click OK.

Before we continue, we need to export the root certificate; is needed for the next section. Right click your Enterprise Root CA and choose Properties.

On the General tab click View Certificate.

Once the certificate opens, go to the Details tab and hit the Copy to File button. Follow to wizard using the default settings and save the certificate somewhere on your local hard drive.

Now we need to create a domain policy so all the clients in the domain know about the new OID. Once the policy is created navigate to Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities. Right click the folder and choose Import.

Follow the wizard and select the certificate we exported a few seconds ago. Now right-click the certificate and choose Properties.

Go to the Extended Validation tab, and in the Add OID box paste the OID I told you to copy when we created the Issuance Policy. Once you paste the OID click the Add OID button then OK.

Now you can either wait between 90 and 120 minutes for the new policy to be processed by all the clients in the domain, or force the clients to process the new policy. Since I have a small environment I will force the clients by issuing the gpupdate /force command. On the Web server open the Certificates MMC console then right-click the Personal folder and choose All Tasks > Request New Certificate.

On the Request Certificate screen on the wizard click the Details arrow of the EV Certificate then hit the Properties button, because we need to provide more information so the enrollment will succeed. If you don’t see your certificate here is because you did not add the Web server computer to the Security ACL on the certificate template.

Here the most important option is the Common Name option. Once selected type the FQDN that clients will use to connect to the web site. You will have to add Organization and Country too. Click OK when you are done. If you are wondering why I typed www.vkernel.local instead of the name server, is because I created a CNAME record in my DNS zone that points to the Web server, so my client don’t have to memorize the name of the server.

In the Certificate Enroll wizard click the Enroll button.

Once the certificate is installed you can see its properties. It has a private key and the Issuance Policy name we created.

Let’s test the certificate to see if we can get a green bar in IE. Install the certificate on your web site and from a client (domain client) type the FQDN address present in the Common Name of the certificate. And hooray, it works. We did a pretty good job here .

To demonstrate this I will use a Domain Controller running on Windows Server 2008 R2, and a Remote Desktop Session Host server also running on Windows Server 2008 R2, joined to the domain. On the Domain Controller I installed the Enterprise Root Certification Authority, so looks like we are going to use our internal CA; since the budget is tight.
To start, on the RD Session Host server and open a certificate mmc (Start > Run > mmc.exe), because we need to request a proper certificate from our internal CA to sign those applications.

Here go to File > Add/Remove Snap-in, and from the Available snap-ins list select Certificates and click Add.

On the window that just opened select Computer Account then click Next.

Select Local Computer and click Finish, and OK.

Expand Certificates > Personal and click on the Certificates folder. As you can see we already have a certificate that we can use to sign applications, but this is a self signed certificate, and is kinda useless.

Right click the Certificates folder and choose All Tasks > Request New Certificate.

Click Next on the Before you begin screen.

Leave Active Directory Policy Enrollment option selected and continue.

Check the Computer box and click Enroll.

If the certificate was installed without errors, a success message will appear next to a green check box. Click Finish to close the wizard.

As you can see we have another certificate installed, but time it was issued by a Certification Authority. You can now close the certificates console.

Now, on the RemoteApp Manager click the Change link next to Digital Signature Settings.

On the window that just opened check the box Sign with a digital signature, then click the Change button.

Select the certificate issued by our internal CA then hit OK. To find out which one is it you can click the link Click here to view certificate properties.

Click OK to save and close the RemoteApp Deployment Settings window.

Now if you try to open a virtual application from a client, you still get a warning message but now you have the option to suppress that by checking the box Don’t ask me again for remote connections from this publisher. And as you can see the application is signed by RD Session Host server certificate we just installed.

Looks like everything worked out just fine, and all you need to do is train your users to open only signed applications. Good luck with that .

If you have the same problem just go to the Advanced tab of your RDC (Remote Desktop Client) and click the Settings button.

Here clear the box Bypass RD Gateway server for local addresses, and click OK to save the changes.

Now connect to your internal network and you will see the difference, the connection and the Desktop Experience is faster than before and no more lag.

To start let’s import the captured image in MDT and create a task sequence for it, so right-click the Operating Systems folder in MDT and choose Import Operating System.

Select the Custom image file option.

Here select the image we captured in part three. If you saved the image in the default path, then is located in the Captures folder in your Deployment Share. If you want to move the image instead of copying it check the box Move the file to the deployment share instead of copying them.

On the Setup screen select the first option, Setup and Sysprep files are not needed. Since we already have a Windows 7 operating system imported in MDT with full set of source files (not a .wim image) we don’t need the second option. The deployment wizard needs the Setup.exe and other files from the Windows 7 DVD for deployment. If your MDT Operating Systems folder is empty, and no operating system with full set of source files is present, then you will need to select the second option Copy Windows Vista, Windows Server 2008, or later setup files from the specified path. The version of the operating systems must match, meaning you can’t have a Windows Vista or a Windows 7 Starter image with full set of source files and you deploy Windows 7 Enterprise.

Specify a directory name for the image and click Next.

Click Next on the Summary screen then Finish to close the wizard.

Now let’s create a task sequence for this image. Right click the Task Sequence folder and choose New Task Sequence. Complete the required information in the General Settings page and click Next.

Choose Standard Client Task Sequence and continue the wizard.

Select the captured operating system and click Next.

Do not specify a product key here, we are going to use rules for that in just a moment.

Complete the boxes on the OS Settings and continue.

Provide a local Administrator password and click Next. Finish the wizard.

If you want to update the Deployment Share, don’t do it, because we need to create some rules for automation. To create those rules right-click the Deployment Share name and choose Properties.

Here click the Rules tab, and as you can see we already have some rules, but they are not enough for our environment.

I’m going to paste here the rules I am using for my Windows 7 deployments, and you are welcome to use them for your environment. Remember, this rules are not going to work if you deploy Windows Vista or Windows XP, because the wizards are different on those operating systems. Modify this settings according to your environment; the last line is if you have a WSUS server in your network.

_SMSTSORGNAME=Adrian Costea's blog.
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipDomainMembership=YES
     JoinDomain=vkernel.local
     DomainAdmin=Adrian
     DomainAdminDomain=vkernel.local
     DomainAdminPassword=admin
UserDataLocation=NONE
SkipUserData=YES
TimeZone=130
TimeZoneName=GTB Standard Time
SkipTimeZone=YES
SkipBitLocker=YES
SkipBitLockerDetails=YES
UserLocale=en-US
UILanguage=en-US
SkipLocaleSelection=YES
SkipApplications=YES
SkipComputerName=YES
SkipSummary=YES
SkipFinalSummary=NO
SkipTaskSequence=YES
TaskSequenceID=003
wsusserver=http://server-wsus

We are not done yet, the log on-screen still appears when the clients boot from the network and try to connect to the Deployment Share. To resolve this, click the Edit Bootstrap.ini button on the Rules tab. Put the following text at the end:

UserID=Adrian
UserDomain=vkernel.local
UserPassword=admin

keyboardLocale=en-us
skipbddwelcome=yes

Again modify the settings according to your environment. Close the Bootstrap.ini file and save the changes. Click OK on the Deployment Share Properties.

Now update the Deployment Share using the default settings. As you can see in the screen, the wizard detected some changes and it needs to regenerate the boot images.

After the update process is done, we need to replace the boot image in the WDS server with this new one, the one that contains the log on credentials to the Deployment Share. Delete the old image from the WDS server, then right-click the Boot Images folder and choose Add Boot Image.

Choose the x64 boot image and finish the wizard. Sometimes the new boot image is not recognized by the WDS server; in that case I just restart the WDS service.

Now is time to deploy and see how it works. I recommend you test o a single machine, and if everything works well, deploy to the rest of the systems. Force a client to boot from the network, and after the WinPE loads into the client memory, the system starts formating and copying files automatically, skipping the deployment wizards. This is what we wanted, a fully automated deployment of Windows 7.

Looks like we had a success here, and I want to thank you for bearing with me all this time. Feel free to ask any questions.

Since we already have the boot images created for us by the MDT wizard when we updated the Deployment Share, we can start importing those images, or at least one of them in our case into WDS. By importing that image into WDS, clients will be able to boot from that image and connect to our Deployment Share and proceed with the installation. Now open your WDS console right-click the Boot Images folder and choose Add Boot Image.

Browse for the boot image, which is located in the Boot folder of your Deployment Share. Select the x64 image (LiteTouchPE_x64.wim), since we are deploying a 64 bit operating system. If a 32 bit operating system is deployed choose the x86 image.

Give the boot image a name and description then click Next.

On the Summary screen click Next to import the image in WDS.

When the operation completes click Finish.

Now we have a boot image in our WDS server,

is time to power on a client and force him to boot from the network.

After it boots and you get an error message “A connection to the Deployment Share … could not be made…The following networking device did not have a driver installed”, it means that network drivers are missing from the ISO for that specific network card you are having on that workstation(s). If the error is not displayed you can skip this section.

To resolve the issue, go to the manufacturer web site of that network card, download the proper drivers for Windows 7 x64 (or the OS you are deploying) and import the drivers in MDT. For that right-click Out-of-box Drivers folder and choose Import Drivers.

Select the folder where your drivers are located and click Next.

Now the drivers are imported, but they are not applied to the ISO yet (the boot image). For that you need to update the Deployment Share, then for clients to get the updated boot image, delete the old one from the WDS server, and re-add it again with this new one.

If everything is in order click the  button Run the Deployment Wizard to install a new Operating System.

Provide the credentials to connect to the Deployment Share.

Select the task sequence from the list and click Next.

Type a name for the computer and continue.

Leave the option not to join the computer to the domain.

Since this is a new system we don’t have any user data to restore, so click Next to continue.

Choose your language and other preferences and click Next.

Select the time zone and continue.

We don’t want BitLocker to encrypt our drive, so leave the defaults here.

On the Ready to begin screen click the Begin button to start the deployment.

If the deployment was a success no error should appear on the Deployment Summary screen.

Now that we have our system up and running, is time to prepare the environment for capturing the system, and for that a new task sequence needs to be created. On the Task Sequence folder in MDT, create a new task sequence.

On the Select Template page we need to select Sysprep and Capture.

I don’t know why we need to choose an operating system here, but if we don’t we can’t continue. Finish the wizard using the default settings.

No we need to verify that our rules allow capture. Right-click the Deployment Share and choose Properties. On the Rules tab ensure that SkipCapture is set to NO (SkipCapture=NO).

Like I told you, before anything happens in MDT the Deployment Share needs to be updated, so right-click it and choose Update Deployment Share. Use the default settings on the Update Deployment Share Wizard.

On the client side we need to install the proper drivers for the system and the necessary software. This is just my way to do things, but if you want, you can install drivers and software during the deployment process. I’ll show you in a future post how to do that. For this example let’s install Adobe Reader and Open Office, so our package won’t be so big. After the software and drivers are installed is time to capture the system, create an image of it, then import the image in MDT 2010. For that go to Start > Run, and type the path to your deployment share.

Go into Scripts folder, and here double-click the LiteTouch.vbs file.

On the Windows Deployment Wizard select the Capture Systems task sequence.

Here choose the first option Capture an image of this reference computer since we want to image the system. The default path is fine for me; if you have a share on a file server in your network and want to save the image there, just type the path to that share in the Location box. Give the image a name, then click Next to continue.

Provide the credentials to connect to the network share. I am using my Active Directory account which is member of Domain Admins group, so I have full access anywhere on this domain.

When you’re ready, click the Begin button to start capturing the system.

The system will be syspreped, then it will reboot into WinPE environment and start creating the image. The operation will take some time, and depends of the amount of software you installed on the system.

After the imaging process is done, if you take a look in the Captures folder on your Deployment Share you can see the system image uploaded and ready to be imported in MDT. We will deploy this image in the next part, so bye-bye for now .