In this lab the TMG server is not joined to the domain, but even if it was things still be the same. To be able to connect and use the VMware vSphere console from the outside we need to open/forward three ports on our TMG server, 443 (for security certificate), 902 (for authentication), 903 (for the VM console). For a full list of VMware ports go here. Now, open your TMG console and click the Firewall Policy object. On the Actions pane click the link Publish Non-Web Server Protocols.

On the first screen of the wizard we need to type a name for the rule.

Here, type the IP address of your ESX server, then click Next. This is for the TMG server to know where to forward the incoming traffic.

Since 443 is a standard protocol for security, is predefined in the protocol lists of the TMG server. For the drop-down list select HTTPS Server and click Next.

Since we are connecting for the internet, select External, so the TMG server will listen on that interface for the 443 traffic.

On the Summary page just click Finish to create the rule.

We are not done yet, I sad we need to open three ports, so again, click the link Publish Non-Web Server Protocols in the Actions pane. This time we are opening port 902 for authentication. Give the rule a name and click Next.

Type the ESX server IP address and continue.

Since this protocol is not predefined in the TMG server we need to create it, so click the New button to start the New Protocol Definition Wizard. Give the protocol a name and continue.

On the Primary Connection Information page click the New button to start creating the ports, direction and protocols.

Here on the Protocol Type select TCP, and since the connection is coming from outside to inside on the Direction option select Inbound. On the Port Range boxes type 902 and click OKto close the window.

Back to the Primary Connection Information page click Next to continue.

Here just go with the defaults, because we don’t need secondary connections.

On the Summary screen click Finish to create the protocol.

The new protocol is automatically select for us in the New Server Publishing Rule Wizard. Click Next to continue.

Here select the External network,

and on the Summary screen click Finish to create the rule.

Don’t forget to click the Apply button on the TMG server, to save the configuration changes.

Now we can connect to our ESX server from internet using a FQDN or the external IP address. If your certificate is not trusted you will get a warning, just ignore it.

You might be thing, what about the third port ? Yes, we’ll get to that in the following section, because if we don’t, we can’t open a console to our virtual machines. On the vSphere client console right-click a virtual machine and choose Open Console.

As you can see the connection fails, because port 903 is closed.

If we take a look in the TMG logs the connection is denied for the specified port.

Now let’s open this port so we can use the virtual machine console. Again, in TMG click the link Publish Non-Web Server Protocols on the Actions pane. Give the rule a name and continue.

Type the IP address of the ESX server.

Since this protocol definition is not specified, we need to create it. Click the New button.

Give the new protocol definition a name then click Next.

On the Connection Information page click the New button.

Select TCP on the Protocol type, and Inbound on the Direction list. Type 903 on the port rage boxes.

Now finish the New Protocol Definition Wizard using the default settings.

Back on the New Server Publishing Rule page click Next to continue.

Here select the External listener.

Click Finish on the Summary screen to create the rule.

Again, don’t forget to click the TMG Apply button to save the changes.

Now let’s open a virtual machine console to see if it works. And we have a success, no more KMS error.

If we look in the TMG logs we can see the connection is allowed.

In this guide I am going to show you how to transition from a 2003 Active Directory to a 2008 R2 Active Directory. After the transition is complete and all FSMO (Flexible Single  Master Operations) roles are moved and working, we are going to decommission the old (2003) domain controller. More about FSMO roles on the way. Like I said, a separate server is needed, on which Windows Server 2008 R2 is already running.

Now put your Windows 2008 R2 installation media into the DVD drive of the domain controller, because we need to prepare the forest and the domain to support 2008 R2. If you have autorun enabled on the server and the compatibility message pops-up just ignore it and click OK, since we are not trying to do an in-place upgrade. Open a terminal and change the path to your support\adprerp directory located on the DVD, and type the following command:

adprep32 /forestprep

Hit c then ENTER on your keyboard to start extending the schema.

Now that our forest is prepared we need to take care of the domain too, by issuing the following command:

adprep32 /domainprep /gpprep

Yep… I forgot to raise the domain functional level, so I got an error when trying to prepare the domain.

Go to Administrative Tools and open Active Directory Domains and Trusts. Right click the domain name and choose Raise domain functional level. Select the domain functional level in the drop-down-box, click the Raise button, then OK twice. Be careful with this, because if you raise the domain level to high and still have old 2000, NT domain controllers in your domain they will became unavailable.

Now let’s try the command again. This time it worked, and the domain was prepared successfully.

There is an optional command if you plan to install RODC in your domain.

adprep32 /rodcprep

After we took care of the forest and domain, the next step is to promote the Windows 2008 R2 server as an additional domain controller in this domain. I have a post on how to promote a server as an additional domain controller, and you can find it here. Read it, then come back. We now need to move the FSMO roles, but first I want to talk a little about them. There are five FSMO roles that a domain controller can have; two of them are forest wide (the Schema Master and Domain Naming Master), and the rest of them (Infrastructure Master, PDC emulator, RID Master) are present in every domain in the forest.

Schema Master – controls updates and modifications to the schema. Once the schema is modified or updated, it will replicate to all domain controllers in the forest. As the best example of schema modification is Exchange, if you are familiar with the product. Before you install Exchange you need to extend the schema, and once is extended new tabs will appear on every user account, besides other things. There can be only one schema master in the whole forest.

Domain Naming Master - controls the addition and removal of domains in the forest. There can be only one domain naming master in the whole forest.

Infrastructure Master – when multiple domain exists in your forest, this role takes care of objects that reference objects in other domains. For example you can have a group in one domain that includes users from another domain. If members of that group are moved or renamed, the Infrastructure Master’s job is to identify those changes and update the group membership. The Infrastructure Master role needs to run on a domain controller that is not a Global Catalog (GC), or it will stop updating object information, since the Global Catalog server holds a partial replica of every object in the forest. Another way to eliminate this issue is to make all domain controllers a GC.  There is an Infrastructure Master in every domain and is held by only one domain controller in that domain.

PDC Emulator -  or Primary Domain Controller Emulator is a domain role that performs critical functions of a domain, like:

Password changes – when a user password is reset or changed, those changes are immediately replicated to the PDC emulator.

Backward compatibility – it gives a chance to those people who are still using Windows NT 4.0, to be able to locate a writable domain controller, since the domain controller that holds the PDC emulator registers itself as a PDC and performs all of the functionality that a Windows NT 4.0 Server performs for Windows NT 4.0 based clients.

Group Policy Objects –  every time you open for editing a GPO, is alway done from the SYSVOL folder of a PDC emulator. This is to avoid situations where two administrators might edit the same GPO at the same time on different domain controllers. Without a PDC emulator the two GPO versions could not be reconciled.

Time synchronization –  every PDC emulator in each domain synchronizes its time with the forest root PDC emulator so critical service like Active Directory,  DFS-R, File Replication Service (FRS) function correctly.

Master Browser – acts as a domain master browser for the domain, and when clients browse the Windows Network, a list of computers, domain and servers will appear in that list.

There is a PDC emulator in every domain and is held by only one domain controller in that domain.

RID Master -  or Relative ID (RID) Master is responsible for processing RID pool requests from domain controllers for security principals like users, groups and computers. The RID Master allocates a pool of RIDs to domain controllers, then those domain controllers generate SIDs by assigning a unique RID to the domain SID. The SID of every security principal must be unique. There is a RID Master in every domain and is held by only one domain controller in that domain.

Now that you know the purpose of each FSMO role is time to move them to our new 2008 R2 domain controller. First we need to move the Schema Master, so open a Run command on the 2008 R2 server and type:

regsvr32 schmmgmt.dll

and hit OK, then OK again on the pop-up message.

Open a mmc using the Run command again,

and from the File menu choose Add/Remove Snap-in. From the left side, select Active Directory Schema then click Add and OK.

Right click Active Directory Schema and choose Change Active Directory Domain Controller.

From the list select our additional domain controller, which is the 2008 R2 server, then click OK.

On the message box that pops-up click OK. It appears because we are no longer connected to the Schema Master, since the 2008 R2 server is not holding this role, yet.

Now right-click Active Directory Schema and choose Operations Master.

On the Change Schema Master window you can see the current holder of the schema, which is our 2003 domain controller, and the targeted server selected for schema transfer, which is our additional domain controller. To change the schema holder just click the Change button, and YES on the warning message.

If everything went well a confirmation message will be displayed.

Now the holder of the schema is our 2008 R2 domain controller. You can close the window and the management console.

If you like, you can use the command line to transfer the schema. Press ENTER after every command.

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer schema master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

The next step is to transfer the Domain Naming Master. For that go to Start > Administrative Tools > Active Directory Domains and Trusts. Right click Active Directory Domains and Trusts and choose Change Active Directory Domain Controller.

Select the 2008 R2 server from the list and click OK.

Right click again Active Directory Domains and Trusts and choose Operations Master.

On the Operations Master window click the Change button to transfer the role to the our 2008 R2 domain controller. On the warning message just hit OK, because we are sure that we want to move the role.

If the operation was successful a message will be displayed.

Back to the Operations Master window you can now see the holder of the Domain Naming Master role, which is the 2008 R2 domain controller.

From a command line is like this:

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer naming master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

The next step is to move the domain roles, and this is done from Active Directory Users and Computers console. Here right-click Active Directory Users and Computers and choose Change Domain Controller.

From the list select the 2008 R2 domain controller and click OK.

Now right-click your domain and choose Operations Master.

On the Operations Master window you can see the holder of the domain roles for this domain.

Here on the RID tab, click the Change button to start transferring the role to our 2008 R2 domain controller. Repeat the operation for the other two roles.

And from a command line:

ntdsutil
roles
connections
connect to server server-2k8.vkernel.local
q
transfer rid master
transfer pdc
transfer infrastructure master

Replace server-2k8.vkernel.local with your own server name, and click YES on the warring message that pops-up.

Before we start decommissioning our 2003 domain controller, I recommend you wait a while for the replication to finish between domain controllers. I can’t tell you how long because it depends on you replication topology between sites (if you have sites), so be careful before you decommission your old domain controller(s). You can check or troubleshoot replication using replmon and repadmin. If everything is all right, and replication took place is time to demote our 2003 domain controller. I have a post on how to remove a domain controller from a domain, and you can find it here. After the removal is successful there a couple of things that need to be done:

Remove the IP address of the 2003 server (former domain controller) from the DNS box on the new domain controller (2008 R2). This is only if you don’t want that server to act as a DNS server in your domain, like in this case.

Sometimes the records of the demoted domain controller(s) are not deleted from DNS, so you will have to do that manually. Expand every sub folder in your _msdcs. zone and delete those orphan records. Do the same for your domain zone too.

If you don’t have any 2003 domain controllers in your domain, or you don’t plan to ever add them in the future, you are ready to raise the domain and forest functional level.

I will use a single 2008 R2 server joined to the domain, which will hold all the RDS role services, well…almost all; you will see there are quite a few. All this role services can be installed on separate servers, and is recommended for large environments, but for the sake of this example we are going with a single host. To start open Server Manager, right-click Roles and choose Add Roles.

On the Select Server Roles page check the Remote Desktop Services box and click Next to continue.

I told you there are quite a few RDS role services, and since we are here I want to tell you something about each one of them before continuing.

Remote Desktop Session Host – formerly known as Terminal Server, enables users to connect and run applications just like they where using a full desktop. Clients connect to the RD Session Host using RDP client, which is integrated in every version of Windows.

Remote Desktop Virtualization Host – this is a Hyper-V server that is holding virtual machines for users or pools of virtual machines. They connect to this virtual machines using a RDP client and use them as a day-to-day workstations. Think about hospitals, if a doctor works on a computer connected to a virtual machine on the RD Virtualization Host, and that computer crashes, the doctor simply moves to another physical computer and reconnects to his virtual machine; the session or data is not lost.

Remote Desktop Licensing – this service is taking care of the licenses used by clients and licenses issued to them.

Remote Desktop Connection Broker – is used for load balancing and reconnection to RD Session Host servers. If one of the RD Session Host fails, users are redirect to another one available without losing their work. A small interruption of the session is possible or users have to reconnect to get their session back.

Remote Desktop Gateway – is for those users that need to connect from outside of the company. This is very useful for administrators, because they only need to open port 443 on the firewall, witch may already be opened if the company has a secure web site publish to the internet.

Remote Desktop Web Access – this service enables users to connect to remote applications and desktop from a web browser. If users are working from a Windows 7 machine they can connect to those applications from the Start Menu.

Now that you know what each role service does, let’s continue with the installation. Select all the role services except RD Virtualization Host and choose to add the required role services when the Add Roles Wizard window pops-up. We are going to take care of RD Virtualization Host in a future post, because is more delicate. Click Next to continue.

On the following screen we have a warning, telling us that applications should be installed after the RD Session Host installation, or they might not work as expected.

In the next screen we have two authentication methods:

Require Network Level Authentication – it enhances the security of a RD Session Host server by authenticating the user before the session is created. It is supported only by clients with a Remote Desktop Client version 6 and greater, running on Windows XP SP3 or Vista. Windows 7 is already equipped with version 7 of the RDC.

Do not require Network Level Authentication - using this option the authentication occurs later in the connection process. This should be used only if yo have RDC older than version 6.

Select  Require Network Level Authentication and click Next to continue.

Specify the licensing mode you are using in your company and click Next.

Here you can add which user groups can connect to this RD Session Host server.

You can provide extra functionalities to users, so they have a similar experience to a Windows 7 desktop if you check those boxes. By doing this more bandwidth is required and processing power on the RD Session Host server.

The RD Licensing Configuration screen is for those that still have RD Session Host servers running on Windows versions older than 2008 R2. In this example we have only 2008 R2, so leave the defaults and continue. If you are using only 2008 R2 server Microsoft recommends you configure the license server from the RDS Host configuration tool.

For clients to be able to communicate in a secure matter a certificate is needed on the RD Gateway server. You can use a commercial certificate, an internal one or a self signed certificate. For this example we are going to create a self signed certificate, even if is not the best choice. I will show you in a future post how to install a proper certificate on the RD Session Host server and the RD Gateway server. The RD Gateway server is very sensitive when it comes to security, so you need to have a proper certificate, if not users will not be able to connect.

Now we need to configure which uses and computers have the right to connect to this RD Gateway server. Click the Now button to start creating the polices, but first let me explain what RD CAP and RD RAP are.

RD CAP or Remote Desktop Connection Authorization Policy – by configuring this policy you specify which users and groups will have the ability to connect to a RD Gateway server. You can even specify that only users using a smart card can connect.

RD RAP or Remote Desktop Resource Authorization Policy – after RD CAP is authenticating users and groups, with RD RAP you can specify which computers in the internal network those users or groups can access.

In this screen we have the option to add the user groups that will be associated with RD CAP and RD RAP.

Here enter the name for the RD CAP policy; we also need to select the authentication method, but since I don’t have a smart card I will let users authenticate using their passwords.

Name your RD RAP policy, and create a group in your Active Directory where you put all the computers that users can access through this RD Gateway server. If you want to you can go with the second option and let users connect to any computer in your network that has Remote Desktop enabled.

Now just click Next and finish the wizard using the default settings. After everything is installed choose to reboot the server.

After reboot the wizard is resuming the installation and when is finished you will have some warnings. Just ignore them, because we are going to configure them in a future guide.

If you expand Roles > Remote Desktop Services from Server Manager you can see all the RD role services installed.

For this guide I have a single forest and a single domain with two Windows 2008 R2 domain controllers (Server-DC and Server-2k8) in one site. We are going to decommission the second domain controller which is Server-2k8.vkernel.local, so let’s get started. Ohh …I almost forgot, this server does not hold any FSMO roles; now log in to Server-2k8, click Start > Run, type dcpromo and click OK or press ENTER.

The Active Directory Domain Services wizard is displayed. Just click Next to skip the Welcome screen.

When you click Next on the Welcome screen a message pops-up, informing us that a Global Catalog server should exist in the domain before you decommission this one. Just click OK because our first domain controller (Server-DC) is also a GB server.

On the next screen we have the option to delete the domain by checking the box Delete the domain because this server is the last domain controller in the domain. You need to be very careful with this, because you can destroy the domain and clients will not be able to log in, besides other things. In this example we are going to leave the box unchecked, so click Next to continue.

Here type the new password for the local Administrator account.

On the Summary screen click Next to begin the removal process.

On the window that pops-up we have the option to automatically reboot the server by checking the box Reboot on completion.

When is done click Finish and restart the server. This screen will not appear if you previously checked the box to automatically restart.

As you can see after restart the server is now part of the domain, just like a file server or a client. You can log in using a domain or a local administrator account.

After you are logged on, you can see that Active Directory Snap-ins are still present on Administrative Tools. To remove them, open Server Manager and from the Roles section choose Remove Roles, then clear those roles boxes and click Next.

There’s one more thing we need to do, we need to delete the former domain controller from the sites link. From a domain controller, and in this example there is only one left, open Active Directory Sites and Services from Administrative Tools. Expand Default-First-Site-Name > Server, identify the name of the server we just decommissioned, right click on it and choose Delete. Click Yes on the warning message. Your site name may be different, or you may have multiple sites, be careful which server you delete.

The vCenter server that I will use here is part of a local Microsoft Active Directory domain, so the new user will be a domain user. If you don’t have an AD environment, that’s no problem, you just create the junior admin account on the vCenter server machine; I will show you that too, later. First let’s start by creating the user account in Active Directory, so right-click your OU and choose New > User. Complete the boxes and click Next.

Now choose a password for the junior admin to use and finish the wizard. The account is now created are ready to be used.

If you don’t have an AD environment just create the user account on your vCenter server. Right click Computer, choose Manage, and expand Configuration > Local Users and Groups. Create a new user account by right clicking the Users object and choose New user. On the New user box complete the requirements and clear User must change password at next logon. Click Create.

Now open your vCenter client console and connect to the vCenter server using an administrator account. Once the console is fully opened click the vCenter server name then go to the Permissions tab.

Here right-click and choose Add Permission.

On the Assign Permissions window click the Add button.

Choose your domain from the Domain list and now all the users and groups from the AD domain should appear under Users and Groups. Select the junior admin account we created before and click the Add button. If you want to add another user or group, just select it and click the Add button again. When you’re done click OK.

Back to the Assign Permissions window, we have our junior admin account. The last step is to assign the necessary permissions to this account, and you can do this from the Assign Role box. For the sake of this example just leave it to Read only. If you want this permissions to propagate on all your ESX hosts, folders, Pools etc, leave the Propagate to Child Objects box enabled. Click OK when you’re done.

The account is added in the Permissions tab on the vCenter server, with the rights we just configured.

Now let’s see from a client perspective. Log in to a client computer using the junior admin account and connect to your vCenter server using the same account. I will use a Windows 7 machine on which I installed the vSphere client.

Since the user has read only permissions on the vCenter server, he can see all the vCenter infrastructure. Right click on one of the objects (ESX server, virtual pool, folder etc) and you should see that access is denied for the user to shut down, reboot, create new virtual machine etc.

If you want to be more granular with permissions, you can add the user account on a server level, then the user will only be able to see that specific server. More about vCenter permissions in a future post.

To start open your SCVMM console and in the Actions pane click New virtual machine.

On the first page of the wizard we have the option to create a new virtual disk or use an existing one. If you have an existing virtual disk and want to use it, you need to place that virtual disk on the library folder before it appears on the inventory, when you click the Browse button here. As you can see I already have a virtual disk from a Windows XP machine.

For this example we are not going to use an existing virtual disk, so click the radio button Create new virtual machine with a blank virtual hard disk then hit Next.

Give the new virtual machine a name and a description and continue the wizard.

Here is where we configure the virtual machine hardware profile; add, remove, and configure devices. After the profile is configured we have the option to save it by clicking the Save as button, in case we need to create a new virtual machine with the same hardware again. Make your changes then click Next.

On the Select Destination screen we have the option to either place this virtual machine on a host or the VMM library. If you place it in the library, you can create clones or use it as a template later on, but in this case we are going to place it on a Hyper-V host, so select the first option and click Next.

If you have more than one host select the one on which to place this virtual machine then continue the wizard.

Type the path where this virtual machine should sit on the Hyper-V host. Since I don’t have a dedicated volume to place my virtual machines, I will use the system drive, but just for the sake of this example. Under any circumstances do NOT, I repeat do NOT use the system volume for virtual machines storage on a production environment. If the path you choose here was not in the virtual machine paths on the VMM server you can check the box Add this path to the list of default virtual machine paths on the host, to add it.

Decide if you need network connection for the virtual machine, and if you do, select the adapter from the drop-down list.

On the Additional Properties page, choose if you want the virtual machine to be automatically powered on when the Hyper-V host starts (after a power failure or restart), and what should happen with the virtual machines when the host shuts down, then select the edition of the operating system. Click Next when you’re done.

On the Summary screen we have the option to start the virtual machine after is created, and view the PowerShell script for all this actions. Click the Create button to start creating the virtual machine.

The process will take just a few seconds,

and at the end we have a new virtual machine ready for installation. I will talk in a future post about virtual machines installations.

For this lab I prepared a WSUS server running on a Windows Server 2008 R2, and two clients, one is a Windows XP machine and the other one is a Windows 7 machine. I suppose you already have your WSUS installed, if not read this post on how to install it. That specific post is about installing WSUS on a server that is part of a domain, but the same methods applies if you are installing WSUS on a server that is part of a workgroup. Now that our WSUS server is working, we need to take care of the clients, and there are two ways: editing the registry, or configure the local group policies. I’ll show you both in just a moment.

To begin go to the Windows XP client and click Start > Run. Here type gpedit.msc and hit ENTER.

In the Group Policy Management Editor expand Computer Configuration > Administrative Templates > Windows Components > Windows Update. As you can see in the Windows Update folder we have a bunch of GPO for the Windows Update configuration.

This part is very simple, just configure the policies to point this client to the WSUS server, and set the update check interval, as a minimal configuration.

After you’re done with the GPO force the policies to apply by issuing the gpupdate /force command. Now open Automatic Updates from the client Control Panel, and take a look at the changes. As you can see everything is grayed out and configured accordingly to your policy settings.

Force the client to check for updates by issuing the wuauclt /detectnow command. After a few moments the Windows XP machine should appear in the created computer group on the WSUS server. Do the same steps for the Windows 7 machine, but don’t forget to change the Enable client-side targeting policy, or your Windows 7 client will appear in the Windows XP computer group on the WSUS server. This applies only if you created and configured computer groups.

Now that we configured these two clients to get their updates from the WSUS server what about the rest of them ? Is a lot of work to go and configure the local group policies for every client. The solution is editing the registry using a script. Go to any one of these two clients and open the registry editor using Start > Run type regedit then hit OK. Expand HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Here you can see all the settings we configured previous using the local group policy editor.

Click the Windows Update folder and from the File menu, choose Export and save the file on you local or network drive.

Now, all you have to do is go to every client in your network and double-click this registry file to import the settings.

The certificate is going to be issued by a Microsoft Windows Internal CA running on Windows Server 2008 R2. I also have a Windows 7 host joined to the domain, on which I installed the VMware vSphere Client to connect to my ESXi 5 server. If you don’t have an ESXi 5 host available for testing you can use ESX 4.0 or 4.1, and it will work just fine. There is no vCenter server present on this lab configuration, so the connection is made directly to the ESXi host. Now like I said we need to get rid of this messages:

and for this the certificate needs to be trusted; issued by a trusted CA. To get started first you need to download and install OpenSSL on you Windows 7 machine, then create the request. For this example I will create a SAN certificate, so I can use it on multiple hosts and connect to them using either the FQDN or the NetBIOS name of the server. A detailed post on how to request normal certificates and certificates with a SAN attribute can be found here, so go read it then come back. I presume you finished with the installation of OpenSSL, so let’s create the request by issuing the following commands, one by one:

C:\OpenSSL-Win64\bin\openssl genrsa 2048 > rui.key
C:\OpenSSL-Win64\bin\openssl req ‐new ‐key rui.key > rui.csr

Complete the required information and make sure on the Common Name you type the FQDN of you ESX/ESXi host. In my example here I typed a descriptive name of the certificate because all the names are in the SAN attribute of the certificate.

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. Now open your Microsoft CA web page and choose Request a certificate > advanced certificate request > Submit a certificate request by using a base-64-encoded… then paste the content from you clipboard in the Saved Request box and choose Web Server from the Certificate Template. Click the Submit button, then YES on the warning message.

The certificate was issued. Check the Base 64 encoded radio button and download the certificate to the bin directory of OpenSSL.

We now need to change the format of the certificate so the ESXi host can recognize it. For this issue the following command:

openssl x509 ‐in ESXi.Certificate.cer ‐out rui.crt

where ESXi.Certificate.cer is the certificate issued by the Windows Internal CA, the one we just download it.

The next step is to upload the certificate and the private key (rui.crt and rui.key) to our ESXi host, and for this we will use WinSCP.

For you to be able to connect to the ESX/ESXi host using WinSCP, the SSH server service need to be enabled on the host, and port 22 opened.

Now follow the path etc/vmware/ssl and you should be able to see the self signed certificate of the ESXi host. Make a backup, then copy our certificate and private key in this directory, replacing the default ones. Reboot the ESXi host.

After the server is back online connect to it using the VMware vSphere Client. The certificate error should not appear any more. Now let’s try using a browser and connect to our ESXi host. As you can see the connection is now trusted.

And here is my certificate with that “fancy” name . On the SAN attribute you can see that I have multiple FQDN and NetBIOS names, so I’m able to use this certificate on multiple servers without requesting so many certificates, and connect to those servers using either the NetBIOS or the FQDN.

For this guide I have a Windows Server 2008 R2 Enterprise as a domain controller and DNS server for the forest/domain. We will add to this domain an additional domain controller also running Windows Server 2008 R2 Enterprise. I presume that your DNS and Active Directory infrastructure is working well, and no problems exist in the environment. Before we begin, the network adapter for the second server needs to be configured with a static IP address. On the Preferred DNS server box type the IP address of the domain controller, then click OK to save the changes.

Now go to Start > Run and issue the dcpromo (Domain Controller Promotion) command.

Some Active Directory binaries need to be installed on the system before the Active Directory wizard will pop-up.

On the Welcome screen leave the Use advanced mode installation option unchecked, because this is for advanced stuff that we don’t need right now.

The compatibility screen is for those that are still using NT or other non-Microsoft clients, but is not our case since we have only 2008 R2 operating systems.

Choose Existing Forest then Add a domain controller to an existing domain.

Here type the domain name where you plan to install this domain controller, then set the credentials to connect to that specific domain. You need to use a Domain Admin account for this operation to succeed.

Now the domain we just typed is verified and displayed on the Select a Domain page. Click Next to continue.

If you have more sites in your environment, select the one that corresponds to this domain then click Next.

Now you have the option to install the DNS service on this server and make it a global catalog. In my environment I can’t install this server as a RODC because my forest functional level is still in mixed mode (Windows 2000 compatible). No stress, if I decide later to install a RODC all I have to do is raise the forest functional level to 2003 mode. Leave the defaults and continue.

If you get the following warning screen, don’t worry, just click YES and continue. This warning appears because the server is not part of the domain, and the wizard can’t create a delegation for this DNS server in the parent zone. During the domain controller promotion this will be fixed.

Here you have the option to change the path of the Active Directory database and log files, but I’m going with the defaults.

Type a strong password for the Active Directory Restore Mode and continue.

On the Summary screen we have the option to export the settings that we just configured through this wizard; so if you need to deploy multiple domain controllers on your domains you can do it silently using this settings. Off course some changes are needed on the file, but you get the idea. Click the Next button to start the installation.

Now the wizard is installing the necessary services, and is setting the correct permissions for this domain controller.

After restart you can log in with your domain admin account.

Now in the Active Directory Users and Computers you can see two domain controllers,

and in the DNS zone a proper entry was created for the server.

If we take a look at the Name Servers tab, we can see that both domain controllers are listed here acting as DNS servers for the domain.

To give you an idea of how my ESX 4.1 server looks, I attached a picture. After the upgrade process every virtual machine, pool, settings should be the same.

Before you start the upgrade process backup your virtual machines, just in case something goes wrong.

Now we can start the upgrade process, so reboot or power on the server and boot from the ESXi 5 installation media.

The first screen is telling us to check the hardware compatibility guide to see if ESXi 5 is supported on this server. To see if your hardware is compatible with this version of ESX server click here. Now press ENTER to continue.

Read and accept the EULA then continue by pressing F11.

The installer will scan the hardware for a few seconds, then will display the storage devices present (recognized) on the server. If you have more than one drive connected choose the one where ESX 4.1 is installed, then press ENTER to continue.

This one is a very important screen. If you make the wrong decision here you can erase your old ESX server and your VMFS datastore.

Migrate ESX, preserve VMFS datastore – will upgrade the version of ESX server, and all our virtual machines and settings will be preserved.

Install ESXi, preserve VMFS datastore – will erase the old ESX server, and it will preserve the virtual machines but not the server settings. After the upgrade is finished you have to add all your virtual machines to the inventory, by hand or by using a script (PowerCLI).

Install ESXi, overwrite VMFS datastore – will erase everything and install ESXi 5.

For our example here, choose the first option and press ENTER to continue.

On the confirmation screen press F11.

The installer starts the upgrade process, which will take a few minutes.

After is done, you need to press ENTER to reboot the server.

And here is our new ESXi 5 host, successfully upgraded,

with our virtual machines and settings preserved.

At the installation page wizard choose your language, time format and keyboard input, then click Next.

Here click Install now.

Select Server Core Installation.

Read and accept the EULA then click Next.

Because this is a fresh installation on a new server we have nothing to upgrade from, so click Custom (advanced) to continue.

Create your partitions and select the one for the operating system installation. Since I have a small hard drive I will use all the available space for the operating system. Click Next to start the installation process.

Now the wizard starts copying the necessary files for the installation, but don’t go too far because in a few minutes it will finish.

Click OK and provide a complex password.

We now have completed the system installation. As you can see there is no Start Menu, and all you have is a terminal console. In future posts I will show you to configure this 2008 R2 Core Server.

In this first example is important that the virtual machine should not have snapshots. The reference virtual machine (Windows.7.Enterprise) is located on the Hyper-V host C: drive, in a folder called HV-Machines. Inside HV-Machines folder create another folder and give it a distinctive name, so you can recognize it. I called mine Windows 7 Clone. Now copy the virtual disk (the *.vhd file) from the Windows.7.Enterprise machine to the Windows 7 Clone folder. If you want to, you can rename the copied virtual disk after the folder name, but is not necessary, is just that I like to have the virtual disk files named after the virtual machine that I will create.

Open Hyper-V manager and create a new virtual machine from the Actions pane. Give the virtual machine a name, and I recommend you name the virtual machine after the folder we just created “Windows 7 Clone”. It will be much easier when troubleshooting. Now choose to store the virtual machine in the folder “Windows 7 Clone”. This is only if you want to have the configuration files and the virtual disk in the same folder.

Continue the wizard until you reach the Connect Virtual Hard Disk page. Here instead of creating a new virtual disk we will go with the second option and use an existing virtual disk. Click the Browse button and select the virtual disk we just copied in the “Windows 7 Clone” folder.

Finish the wizard. Now we have an exact copy of the reference virtual machine. Don’t forget to change its name an IP address, if is a static one.

In the second example we are going to use the Hyper-V export function to clone the virtual machine. Using this method you can have snapshots and still being able to clone the machine. To start click the reference virtual machine (Windows.7.Enterprise) in the Hyper-V console, then in the Actions pane click the Export link.

On the Export Virtual Machine window click the Browse button and choose a place where to save this virtual machine, then click Export to start the process. Is going to take a while so be patient. When the export process is finished the Cancel export link in the Actions pane will disappear.

Back in Hyper-V manager console click the link Import Virtual Machine in the Actions pane.

In the window that opens we have two radio buttons and a check box. The first radio button, Move or restore the virtual machine (use the existing unique ID) is going to import the virtual machine and preserve its ID’s. This option is used when importing to a different Hyper-V server. If you import a virtual machine, and on the same Hyper-V server that ID already exists you will get an error message, and the import process fails.

The second radio button, Copy the virtual machine (create a new unique ID), like the name implies, it will create a new ID for the virtual machine you are importing. This is used when you use the same Hyper-V host to export and import virtual machines, like in our case. The check box is there if you want to import the same virtual machine for more than one time, without going through the export process again. Since we are using the same Hyper-V host to import the virtual machine, and another one (the reference machine) exists with the same ID, select the second radio button. Now click Browse and select the exported virtual machine folder, then hit Import. I changed the folder name because this is how I’m going to call my virtual machine in the Hyper-V console.

Looks like I have a warning message after the import process finished. This is because I forgot to unmount the Windows 7 ISO from the reference virtual machine before exporting. I’ll just ignore it and click Close.

The last step is to rename the virtual machine in the Hyper-V console so we can distinguish it from the original one. Again don’t forget to change its name and IP address if is a static IP.

That’s it folks, hope it was informative for you.

For this lab I’m going to use an Enterprise Windows CA running on Windows Server 2008 R2 SP1. If you don’t have a 2008 R2 box, you can use a Windows 2003 server edition. To be able to issue SAN certificates using our internal Windows CA we need to configure it first, so connect to the CA server and open a terminal. Here type the following command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Don’t close the terminal yet, because we need to restart the Active Directory Certificates Services service. Type the following command to restart the service:

net stop certsvc & net start certsvc

Our internal CA is now ready to issue certificates that contains the SAN extension. Let’s request some.

For this exercise you need to configure your Internal CA web page to use an encrypted connection. Issue a WEB certificate from the internal CA, or create a self sign certificate, then bind the certificate to the web site.

Open a browser on one of your clients, or even the localhost and type the CA server web address into your browser (eg: https://MyInternalCA/certsrv). On the Welcome page click Request a certificate.

Click advanced certificate request.

Click Request and submit a request to this CA.

On the warning message click the OK button.

On the Certificate Template box select Web Server.

Now I want to show you something fancy. Usually in the Name box you would type the common name of the certificate, but this time we are not going to. Just type something like SSL Certificate or My SSL Certificate.

Complete the rest of the boxes until you reach the Attributes box. Here we provide the domain names that this certificate should protect. The syntax is like this:

san:dns=mydomain.com&dns=mydomain.org&dns=mydomain.net

If you want to, give the certificate a friendly name than click the Submit button. When the warning pops-up click Yes.

To install the certificate click the link Install this certificate. Now if we open the user certificates store we can see our certificate installed, and with a SAN extension that contains the protected domain names. Just look at the Issued to section. I told you it will be fancy .

Remember, this “fancy” certificate is just for fun, you can use it with your internal CA, but not with a commercial CA, because it will cost you more since you pay for the domains in the SAN extension. Another problem with this “fancy” certificate is that some software will give you a certificate error message, not being able to recognize the SAN extension in the certificate (been there). If you have this problem just type the FQDN (common name) in the Name box on the CA web page when you request the certificate.

OK, we created a certificate by completing the information in the CA web page, but what about those of you that have the request in a file ! Don’t worry, this is next. For this part of the guide I created a certificate request using OpenSSL. You can download OpenSSL from this address. To configure it for SAN extension we need to edit the openssl.cfg file from the bin directory.

Here uncomment req_extensions = v3_req line, then paste this:

[ v3_req ]
 # Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names 

[alt_names]

DNS.1 = myfirstdomain.com
DNS.2 = www.myseconddomain.net.net
DNS.3 = myseconddomain.org

Off course replace the domain names with your own. Now open a terminal and go to the OpenSSL bin directory path. Here type the following:

openssl genrsa 2048 > rui.key

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

Now in the bin folder there is a new file called rui.csr. Open the file using notepad or any other text editor, copy the content and go the CA web page. Click Request a certificate > advanced certificate request >  Submit a certificate request by using a base-64-encoded…’ and paste the content from the rui.csr file in the Saved Request box. Under Certificate Template select Web Server and click the Submit button.

Click Download Certificate and save it somewhere on your hard drive, then open it. It should have a common name and a SAN extension. If you want the common name to be something “fancy” like before, on the OpenSSL line Common Name (eg, YOUR name) []: type your desired name.

As a first step I’m going to convert a VMware ESXi 5 virtual machine (a Windows XP machine, because is smaller) using the StarWind converter. This converter does not need the configuration files of the virtual machine, only the virtual hard disk. To start, you need to copy your virtual machine from the ESXi datastore to your local computer (your technician computer), then power up the StarWind converter.

Here choose the source virtual hard disk from our Windows XP machine; the .vmdk file.

In the Destination Image Format screen select MS Virtual PC growable image, but if you have a Hyper-V cluster or you just want the disk to have the space pre-allocated select MS Virtual PC pre-allocated image.

Choose where the destination file should be saved, then click Next to continue.

Now the tool starts converting the VMware image disk to the selected output format, witch is a Hyper-V virtual disk.

When is done, just click Finish to close the StarWind tool.

And now we have a Hyper-V virtual disk converted from a VMware virtual disk.

All you have to do, is create a new virtual machine in Hyper-V and choose Use an existing virtual disk.

We now have a converted VMware virtual machine running in Hyper-V.

As a second step I’m going to show you how to convert VMware virtual machines to Hyper-V format using SCVMM 2008 R2. You can convert a virtual machine with SCVMM using three methods:

- directly from an ESX server host, but for this you need to have a VMware Virtual Center to connect to

- from the VMM library

- from a Windows or NFS network share

Before the conversion, you have to uninstall VMware Tools on the guest operating system of the virtual machine.

Here is a table with the supported operating systems for V2V conversion in SCVMM 2008 R2.

We are going to use the second method for this example. Now go to your Hyper-V library, right click it and choose Explore.

Here copy the VMware virtual machine files from the ESXi 3.5 host. You only need the *.vmx and *.vmdk files

I used a virtual machine from a VMware ESX 3.5 host, because VMM 2008 R2 is not supporting right now the 4.1 and 5 version of ESX. I tried to convert virtual machines from those versions but, alway got errors or the virtual disk was not recognized. More information can be found here.

 Now refresh your Hyper-V library, and after a few seconds the VMware virtual machine should appear in VMM.

It’s time convert this virtual machine, so click the link Convert virtual machine from the Actions pane. You can also right click the virtual machine template and choose Convert virtual machine.

On the Convert Virtual Machine wizard screen click the Browse button.

Select the our virtual machine disk from the library and click OK.

If you want to give the virtual machine a different name you can do this in the Virtual machine name box.

Choose the number of processors and the amount of memory for the virtual machine, then click Next to continue.

Select on witch Hyper-V server the virtual machine should be placed. Now if you take a look at the Rating Explanation tab you have a couple of messages. The first one is telling us that VMM will move the virtual disk to an IDE bus; this is because Hyper-V does not support booting form SCSI bus adapters like VMware does. The second message is about virtual networks, witch is nothing to worry about, since VMware virtual networks have different names compared to Hyper-V virtual networks. Click Next and continue the wizard.

Choose the path for the virtual machine files on the Hyper-V server.

If you want to you can connect the virtual machine to a network, by selecting it from the drop down box.

Change additional properties for this virtual machine then click Next.

At the Summary screen click the Create button to start the conversion.

The conversion starts and is going to take quite a long time. Just be patient.

After the conversion is done, and is successful the virtual machine appears in the Virtual Machines section in VMM.

I was keep getting the same error message:

Error (2606)
Unable to perform the job because one or more of the selected objects are locked by another job.

Recommended Action
To find out which job is locking the object, in the Jobs view, group by Status, and find the running or canceling job for the object. When the job is complete, try again. 

Here is a print screen with the error:

I tried forcing it with PowerShell, I rebooted the server, but nothing, so as a last resort I logged in on the Hyper-V host and deleted the virtual machine from here. Then I went back to the VMM server, removed the host from the console and re-added back in. It worked, my “half” virtual machine was gone now.

To be able to install the Exchange 2010 Edge Server Role some minimum system requirements are needed.

Before we start the installation we need to prepare the machine, and the first step is to add a DNS suffix. For this, right click My Computer and choose Properties. Click the link Change Settings than click the Change button.

We need to add a DNS suffix because the Edge Transport server requires a FQDN for the machine, and is usually installed on standalone servers.

Choose More, and in the box type your DNS suffix. Click OK and restart the server.

After restart open Server Manager right click Features and choose Add Feature. Expand .NET Framework 3.5.1 Features and check the box .NET Framework 3.5.1. Click Next and Install.

Don’t close Server Manager because we need to install a Windows server role now. Right click Roles and choose Add Role. Check the box next to Active Directory Lightweight Directory Services then finish the wizard.

There is one more thing to do, before we start the Edge server installation, and that is to download and install the Microsoft Office 2010 filter pack. You can download it from here, and off course, choose the x64 edition. Now that everything is in place, we can start the installation, so put the Exchange 2010 installation media into your DVD drive. On the initial screen click the link Install Microsoft Exchange.

Skip the Introduction page, and on the second screen read and accept the EULA.

I’m going with the default setting here and not report to Microsoft.

Here click Custom Exchange Server Installation.

Check the box Edge Transport Role and click Next.

For this demonstration I’m not going to joint the CEIP program.

The wizard is now checking if everything is in order for the installation to proceed, and if it is click the Install button. After the installation is done, restart the server.

And here is our new Exchange Edge Transport Server role console. The next step is to configure the Edge server, but that story is for another time.

For this guide I have the following lab configuration

Now let’s configure the networks on the Mailbox servers, and will start with the MAPI (public) network.

The second one is the private network, the one that is used for database replication.

Don’t close the properties of the TCP/IP protocol yet for the private network. Click the Advance button an go to the DNS tab. Here clear the box Register this connection’s address in DNS.

Now change the binding NIC order by going to Advanced > Advanced Settings.

Make sure the public network is on top.

Now open the Exchange management console. Here expand Organization Configuration and click the Mailbox object. To create a DAG you can either click New Database Availability Group on the Actions pane, or click the Database Availability Groups tab. On the New Database Availability Group wizard we need to configure three components:

Database Availability Group Name – the name of the new DAG; no more than 15 characters.

Witness Server – a host that maintains the cluster quorum. This host can be a Windows server joined to the domain, but is recommended by Microsoft to be an Hub Transport server. The witness server can’t be a member of the DAG, but it must reside in the same Active Directory forest as the DAG, and not also running the Mailbox server role. If no witness server is specified in the box, a Hub Transport  server in the same site as the DAG is automatically selected.

Witness Directory – a folder on the witness sever that stores some cluster information.

After you complete the required information click the Manage button to start creating the DAG.

If everything worked out well you should have a green check mark.

Now we need to add the Mailbox servers that are going to participate in the replication process. For that right click the DAG and choose Manage Database Availability Group Membership.

Here click the Add button and select the Mailbox servers.

Click the Manage button to start adding the members to our newly created DAG. This is going to take some time because the Windows Failover Cluster feature must be installed on those Mailbox member servers.

Because the wizard assigns all the available networks to the DAG the replication may occur on the MAPI (public) network creating an increase of traffic. For this reason we need to disable it so the replication can take place only on the private network. Click the DAG, find your MAPI network on the Networks section, right click Replication Enabled and choose Properties.

Clear the box Enable Replication and click OK.

Now our MAPI network is disabled and replication will only take place on the private network, witch is what we want.

We have created a DAG, we configured the network for the DAG, the next step is to add database copies. If your database is located on a different drive than the default one, all the Mailbox servers that will keep a copy of the database will need to have the same drive letter. In my case I have a database called Finance Database located on the E  drive, and the same E drive needs to be present on the other Mailbox system(s). If the same path is not found on one of the replication partners an error message appears when you try to add a database copy.

Now go to Database Management tab, right click the database you want to replicate and choose Add Mailbox Database Copy.

On the Add Mailbox Database Copy page click the Browse button to select the replication partner.

Click the Add button to start creating a copy of the database on the selected server.

If the operation succeeded a green check box appears on the wizard.

Now we have a healthy copy of the database on another Mailbox server as you can see in the Database Copies section.

Let’s see if it really works.

To be able to verify this properly, a user mailbox needs to be created on the mailbox database that is part of the DAG (Finance Database).

Shut down the Mailbox server that holds the active (mounted) copy of the database; in this case is EX01. After a few seconds the Mailbox database should be mounted on the second Mailbox server witch is EX02. You can see this by opening the Exchange management console on EX02.

And user(s) can still access their mailbox(es), even if one the Mailbox servers is down.

Off course you can create multiple databases and configure them for replication, and if you have more then two Mailbox servers who are members of a DAG you can mix and match those databases for better performance and HA.

To start put your vCenter DVD in your optical drive, or mount the ISO image. On the initial screen, click the VMware vSphere Web Client (Server) menu, then the Install button.

Click Next to skip the Welcome page.

Again, Next on the End-User Patent Agreement.

Read and accept the EULA, then continue the wizard.

Complete the customer information.

Leave the default ports here and continue.

Change the installation path if you want, but I’m gonna go with the default one here.

Now, just click the Install button to start the installation process.

After the installation is done, click the Finish button.

The administration web page opens. Ignore the certificate error, and just click Continue to this website.

If you get the Adobe Flash Player page, click the picture in the corner to go and get the Flash Player from Adobe.

Now that we took care of the Flash Player problem, refresh the Web Client Server page. A vCenter Server needs to be registered with the Web Client service before you can manage those vSphere hosts and virtual machines. That, in a future guide.

Here I attached a preview of how a registered vCenter server looks in the web console.

To get started, first we need to request a certificate for the WSUS web site, so open IIS, click the server name, then open Server Certificates.

On the Actions pane click Create Domain Certificate.

On the Common Name box we need to type the name we want appear in the certificate. I recommend to use either the name of the WSUS server, or the FQDN of the server. If you have external clients that use this WSUS server you need to type the FQDN (the internet public address) in this box. But now things are getting a little complicated, because you either need to create a split-brain DNS or create a SAN certificate that includes the FQDN and the WSUS server name. For more info you can read this post. Complete the rest of the boxes and click Next.

Select your internal CA by clicking the Select button, give the certificate a friendly name and click Finish.

Now that we have our certificate in place we need to add this certificate to the web site. Expand Sites and click the Default Web Site. On the Actions pane click Bindings.  Now click Add, on the Type drop down box select https, and your WSUS certificate on the SSL Certificate drop down box.

The next step is to enforce SSL encryption on the following virtual roots:

• SimpleAuthWebService
• DSSAuthWebService
• ServerSyncWebService
• ApiRemoting30
• ClientWebService

Select SimpleAuthWebService and open the SSL Settings.

Check the box Require SSL, and make sure Ignore is selected under Client certificates. Click Apply on the Actions pane to save the changes.

Repeat  this operations for the rest of the virtual roots, mentioned before. By now, the connection to the service should be lost, and a connection error message appears in the WSUS console. This is because the console is trying to connect using the default port 80.

To fix this, open a terminal and issue the following command from <WSUS Installation Folder>\Tools:

WSUSUtil.exe configuressl FQDN of the software update point site system>  (the name in your certificate)

in my case is:

WSUSUtil.exe configuressl Server-WSUS

I managed to get access to the console only after a system restart, but after restart I am connected using SSL.

The next step is to point your clients to the correct url, by modifying the existing GPO or creating a new one. Open the policy Specify intranet Microsoft update service location and type the new url in the form https://YourWSUSserver.

To see if all this is working correctly, go to one of your clients and force the new policy to apply using gpupdate /force.

The gpupdate /force command will just download all the GPO’s and re-apply them to the client, it won’t force the client to check for updates. For that you need to use wuauclt /detectnow.

First let’s see the client update log

WireShark is showing me that an encrypted connection is made between the client (192.168.50.11) and the WSUS server (192.168.50.10),

and updates are downloaded by the client.

To be able to test this in a lab environment if you don’t own a public domain, you can edit the hosts file on an external client and point the FQDN to the external IP of the TMG server.

Before we start to publish the OWA site we need to make some configuration changes on the Exchange server. Open your Exchange console, expand Server Configuration and click the Client Access object. In the middle pane click your Exchange server and select the Outlook Web App tab.

Right click OWA (default Web Site) and choose Properties. Go to Authentication tab, select Use one or more standard authentication methods, and check the box Basic Authentication (password is sent in clear text). Don’t worry the passwords are not sent in clear text, we are going to encrypt the traffic using a certificate.

Now back on the management console click the Exchange Control Panel tab. Right click ECP (Default Web Site) and choose Properties. Go to Authentication tab, select Use one or more standard authentication methods, and check the box Basic Authentication (password is sent in clear text).

For the configurations to take effect we need to restart IIS. Open a terminal and type:

iisreset /noforce

Sometimes the service takes a log time to stop, like in mine case. Wait a minute or two and issue the command again.

The next step is to install a proper Exchange certificate. I have a post where I talked about how to install and configure Exchange certificates here. Read the post, then come back.

Now we need to export the Exchange certificate and import it on the TMG server. Click Start > Run, type mmc. On the console go to the File menu, choose Add/Remove Snap-in, select Certificates and click Add. On the new window select Computer Account > Local Computer, and click Finish and OK. Now expand Certificates > Personal, right click the Exchange certificate and choose All Tasks > Export.

Select the option Yes, export the private key and click Next to continue.

Choose to export all extended properties.

Type a password to protect the certificate.

Specify a path to export the certificate to and finish the wizard.

Now we need to import the certificate on the TMG server. Again open the mmc console and add the Certificates Snap-in like we did before. Right click the Personal folder and choose All Tasks > Import.

Click the Browse button and select the Exchange certificate.

Provide the password to decrypt the certificate. This is the password we set on export. Finish the wizard.

It’s time to create our publishing rule, so open the TMG console and go to Firewall Policy. On the Tasks pane click Publish Exchange Web Client Access.

Give the publishing rule a name and click Next.

Since we are publishing Exchange 2010 OWA, from the list select Exchange Server 2010, and check the box Outlook Web Access.

We are only publishing a single web site, so the default option is OK. Click Next to continue.

The publishing rule will use SSL, so choose the first option.

Type the internal site name, and provide the IP or computer name, so TMG can connect to the publish server. In the internal site name I usually type the external name of the site, so users don’t have to memorize two web addresses. The published server is our Exchange server.

Here type the public name, the one that external users will type in their browser to connect to Exchange OWA.

On the Select Web Listener screen click the New button to create a new listener. The existing one is for HTTP traffic and we need a listener for HTTPS traffic. Name the new listener and continue the wizard.

We need a secure connection, so leave the default selection here and click Next.

Check the box next to External, to listen for traffic coming from the internet.

Click the Select Certificate button, and select the Exchange certificate we imported just now.

On the Authentication Settings page, be sure HTML Form Authentication is the one selected. Click Next.

We do not need SSO, so uncheck the box and continue.

Click Finish to close the listener wizard.

Back to the Exchange OWA publishing rule click Next to continue.

On the Authentication Delegation page select Basic Authentication. This is the type of authentication we configured on the Exchange server.

Click Next leaving the defaults on the User Sets page.

Finish the wizard and apply the configuration on the TMG server by clicking the Apply button. Now let’s see if it works. From an external client access the OWA page in this form https://FQDN/owa.

And now the TMG logs.