By default IIS will recycle its worker processes during the night, in my case IIS 7.5 tells me this happens at 1:04 AM.  You can locate this information in IIS Manager / Application Pools / Highlight your application pool in question and select Recycling under Actions / Edit Application Pool.

So what is recycling all about?  Here is a brief primer;

Recycling is all about stopping any current w3wp.exe processes that are running for a particular Web Application Pool and starting a new one.  The purpose of this maintenance routine is to clear the cache and start afresh! This routine obviously causes SharePoint to be quite slow when accessed for the first time after the recycling process.  This is because when accessing a SharePoint Site/Page for the first time, that information needs to be re-compiled and loaded into memory again.

So what can we do about this first time slowness that occurs every morning?  Wake SharePoint up!

There are an array of scripts that have been developed by 3rd party developers that can be scheduled to run straight after the recycle occurs.  These scripts are usually required to be modified for your Web applications in question.

With the introduction of IIS 7.5 and Windows 2008 R2 however, there is an actual module developed by the IIS team that will integrate directly with IIS allowing you to seamlessly enable your application pools to load your web applications after a recycle occurs.  You can download the extension here; http://www.iis.net/expand/ApplicationWarmUp At the time of this writing, the Application Warm-Up module is still in beta, but I have been using it on our production servers for over a month without any hiccups.

So let’s begin our step by step guide.  Download and launch the executable from the above site.

Click Install and then click Finish.  As you can see, the installation process is quite simple.

Launch IIS Manager and click on one of your SharePoint Sites.  In the middle pane, you will notice a new item listed under IIS titled, Application Warm-Up.

Double Click on Application Warm-Up.

Under Actions located on the far right pane, select Settings

Ensure that both options available are selected and ticked.

We also now need to add a request which is usually the main page of your SharePoint Site.  This is achieved under Actions, Select Add Request and enter the URL of your SharePoint Site.

The last area that you will need to venture into is also located under Actions / Edit User Context.  Here you will need to specify your Authentication settings, otherwise the module will not work and you will receive the below warning message in your Windows Application Even Log.

Log Name:      Application
Source:        IIS Application Warmup Module
Date:          8/03/2010 7:31:43 AM
Event ID:      1003
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      SERVERNAME

Description:
The description for Event ID 1003 from source IIS Application Warmup Module cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

/default.aspx
MACHINE/WEBROOT/APPHOST/SharePoint Central Administration v3/
Unauthorized

Here I have specified “Set Username and Type only” for the mode and “Windows” for the Type.  Lastly, specify an account that has access to load the SharePoint Web Application.

That’s all that is to it.  All you need to do now is replicate this for each SharePoint Web application on each of your SharePoint Web Front Ends.

This neat little module has a number of advantages over scheduled scripts as it seamlessly warms up your SharePoint Web applications regardless of when the Application Pool is recycled including when you re-start your servers or re-start IIS.  Please note, this little module also works with all ASP.Net applications!

Before I let you go, if you are after a neat utility for IIS7, Spencer Harbar has developed an Application Pool Recycle Utility which also incorporates a Warm Up tool  You can download it here; http://www.harbar.net/articles/apm.aspx

Resources

IIS.Net – Application Warm up http://www.iis.net/expand/ApplicationWarmUp

IIS.Net – Using the IIS Application Warm-Up Module http://learn.iis.net/page.aspx/688/using-the-iis-application-warm-up-module/

In today’s post, I will provide you with a step by step guide in restoring your DPM server whilst retaining your DPM database and DPM replicas, and also explain a few gotcha’s that are worth noting that I had encountered during the process.

First item that we need to address is taking a backup of the DPM database itself.  TechNet have an article on “Backing up DPM Databases” http://technet.microsoft.com/en-us/library/bb795642.aspx and in summary you can backup the DPM Database to Tape by using a separate protection group within DPM itself and selecting short-term protection using tape.  Please note that you cannot protect the DPM databases as replicas to disk.  The other 2 methods of protecting your DPM database is by utilising 3rd party backup software or a secondary DPM server.  You can also for good measure take a file copy of the DPM database if you are utilising SQL 2005 Express.  The Database file by default is located under “\%programfiles%\Microsoft DPM\DPM\DPMDB”.  You will obviously need to stop the SQL service first before attempting a file copy.  Microsoft also recommend to take a copy of the configuration folder located under \Program Files\Microsoft DPM\DPM\Config.  This folder contains the DPMA.xml file which is the tape drive remapping file .

So now that we have a copy of the database, here are the steps required to perform a database recovery onto a new server;

• Install Windows operating system and DPM’s requirements.  In my case I installed Windows 2008 R2. (Just a word of note, Windows setup may seem to hang at the partition screen if you have many volumes due to your existing replicas.  I had to wait 30 minutes in my case)
• Ensure that the replicas partition are intact and not accidently deleted.
• Re-install Data Protection Manager and all it’s service packs.
• Using the DpmSync command line tool, run the following command to synchronize the backed up DPM database. 

DpmSync –RestoreDb –DbLoc location –InstanceName server\instance]

In my case, I was restoring from a local copy of the DPM database, so I utilised the following command;

DpmSync –RestoreDb -DbLoc C:\DPMDB2007rtm.bak

• After successfully restoring the DPM database, you will also need to run the DpmSync –Sync command to synchronise the recently restored database.

If we now launch the DPM 2007 Administrator Console and navigate to the Protection Tab you will notice that all your protection Groups are listed, albeit in a consistent state.  This is the best way in confirming that your original DPM database was successfully restored and synced correctly.

You should at this stage force a consistency check against all your protection groups to ensure you have the most up to date copy of your data.

In the second part of this post I will outline some of the issues that I had encountered with the re-installation of DPM 2007 on a Windows 2008 R2 server.  First issue that I ran into was the below error message that I had received when clicking on the Reporting Tab within DPM 2007 Administrator Console;

“DPM could not connect to SQL Reporting Services server because IIS connectivity issues. ID: 3013”

The below message states that I should restart the World Wide Web Publishing Service which in my case did not fix my issue.

The issue is a little deeper than just a simple restart of the WWW Publishing Service and is actually directly related to inadequate permissions attached to the ReportServer Virtual Directory in IIS 7.5.  This issue actually first arose with Windows 2008 and IIS 7 and obviously flows through to Windows 2008 R2 and IIS 7.5.

The fix is quite simple which I will outline in the following steps;

• Navigate to Administrative Tools / Internet Information Services (IIS) Manager, expand Sites / Default Web Site / ReportServer$MS$DPM2007$.
• Under IIS on the middle navigation pane, double click on Handler Mappings

• Under Actions, click on Edit Feature Permissions …

• Ensure that only Read and Script are selected.

• Finally, restart IIS for good measure.

If we now navigate back to the Reporting Tab, we are presented with our Report categories as per the below screen capture.

The next issue encountered is that I had noticed my Exchange Servers Protection group that I had setup was stating that my Replica’s were inconsistent, even though I had attempted to “Perform a consistency check..”

DPM in most instances provides you with some detailed descriptions to their alerts and low and behold my eseutil.exe and ese.dll were missing or were the incorrect version.  It is important to ensure these are up to date in particular with later Exchange service packs.  In my case, I needed to copy the latest versions from my Exchange 2007 Server which was now running Service Pack 2.  There are 2 ways to accomplish this;

1. Install the latest Microsoft Exchange Server 2007 management tools on the DPM server that matches the version and service pack level of Exchange that you are running (in my case it was Service Pack 2). 
2. Copy the eseutil.exe and ese.dll files from your Exchange 2007 server to c:\program files\Microsoft DPM\DPM\bin\.  These files are located under c:\Program Files\Microsoft\Exchange\bin on your Exchange Server.

That’s it!  Hopefully I have provided you with a fairly straightforward method on re-installing Data Protection Manager onto new or existing hardware without recreating the original protection groups and or existing replicas.

As this is my first post for the year, I would like to wish everyone a “belated” Happy Prosperous New Year and looking forward to all your comments and feedback.

References

Using DpmSync – TechNet http://technet.microsoft.com/en-us/library/bb808877.aspx

Protected Computer Software Prerequisites -TechNet http://technet.microsoft.com/en-us/library/bb808827.aspx

1. In-place upgrade
2. Database attach upgrade to a new farm
3. Hybrid approach (Read –only databases or Detach databases)

There is a wealth of information regarding these different approaches on the Microsoft TechNet site under the Upgrade and Migration Resource Center for SharePoint 2010. I will also outline other resources at the end of this article for convenience.

The upgrade model that I have chosen in this article series is the Database attach upgrade approach in which I will outline in this step by step guide.  The upgrade choice you choose is dependent on a number of factors such as how much down time can you afford and whether you are moving onto newer hardware.  All three options have their strong and weak points which is outlined in the following TechNet article; Determine Upgrade approach (SharePoint 2010)

This article is assuming that your SharePoint 2010 environment is up and running (albeit in beta form).  I have published a 3 part series in getting your SharePoint 2010 environment up and running that you can access from the following links;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

When using the database attach method to upgrade your databases to SharePoint 2010, you need to be aware that none of your configuration settings in SharePoint 2007 will migrate.  You will need to ensure that you have replicated your 2007 environment in the newly created 2010 farm.  Some of the items to consider include the following;

• Outgoing email server
• Alternate Access Mappings (AAM)
• Quota templates
• Included paths
• Install any custom or 3rd party features, including web parts, solutions
• Custom site definitions
• Custom CSS

In order for you to perform a database attach upgrade into your SharePoint 2010 environment you need to ensure that you have created a new web application.  If you have not done so, you can follow my step by step guide on Creating your first SharePoint 2010 Beta Web Application and Site Collection.

Step 1 :: Restoring a copy of your SharePoint 2007 content database

Now that we have ensured that all our configuration settings are in place, and that all custom features, web parts and solutions have been re-instated, we can now proceed with our upgrade.  You will need to firstly backup and take a copy of your SharePoint 2007 content database and restore it to the newly created SharePoint 2010 farm.

I’m performing my database restore utilising SQL 2008 Management Console.  Right click on Databases and select Restore Database.

Select your source and destination as follows;

Click on Options and ensure you have selected Overwrite the existing database.

Click OK.

We should receive the following confirmation message once the database has been successfully restored.

Step 2 :: Verifying the Content Database

As you have already noticed from our first article, in particular with the introduction of the preupgrade check tool, Microsoft have done a great job in providing us with the necessary tools to ensure a successful upgrade.  The next tool that we will be using is the Test-SPContentDatabase Windows PowerShell cmdlet.  This cmdlet will test and verify that any custom components that are required for this content database has been installed and configured in the SharePoint 2010 environment.

Test-SPContentDatabase –Name <database name> -WebApplication <URL>

Test-SPContentDatabase –Name WSS_Content_Intranet -WebApplication http://intranet.georgekhalil.com

stsadm -o addcontentdb -url <URL> -databasename <database name>

If one is listed, you can remove the existing attached database by clicking on the actual database name and then clicking on the “Remove content database” check box.

You will receive the above warning which is safe to ignore.  In this instance we are not deleting the actual database but disassociating it from the selected Web Application.  This is the exact same behaviour that was available to us in SharePoint 2007.

We can now proceed and attach our restored SharePoint 2007 database via the following stsadm command line;

stsadm -o addcontentdb -url <URL> -databasename <database name>

In my instance, the command looked as follows;

stsadm -o addcontentdb -url http://intranet.georgekhalil.com -databasename WSS_Content_Intranet

You will eventually receive a message similar to the below advising that the upgrade was completed albeit with errors in my case.  You should review the upgrade log file which is quite extensive and lengthy, and sure enough the errors were all related to missing features etc which I was already aware of.

We can now verify that the upgrade was completed successfully by first navigating back to Central Administration / Application Management / Manage content databases, which now displays the upgraded database under my designated Web Application.

We can also view the upgrade status page which is located within Central Administration / Upgrade and Migration / Check upgrade status.  The page will list all previous upgrade attempts and summarise the number of errors and warnings that may have been encountered.  In my case, there were a number of features that were not installed in the new SharePoint 2010 farm that the current portal relies on.  All of the upgrade logs are located in the following location, providing you with finer detail on the errors and warnings encountered;

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS

By default, your site will retain it’s 2007 theme which Microsoft have done on purpose and you will need to manually change this 2010 if you wish to do so.  This is referred to as the “Visual Upgrade”, providing site administrators the ability to switch to the new look and feel at their own leisure.  This is a great move by the SharePoint product team as the new interface can be quite overwhelming to begin with.  Think about the move from Office 2003-2007 with the introduction of the new ribbon interface.   There was a week or two of frustration for most users before eventually getting the hang of it and finding the new interface to be more productive.

The below screen capture is my upgraded SharePoint 2010 portal running in “SharePoint 2007 theme mode”.

To perform the Visual upgrade, navigate to Site Actions / Visual Upgrade.

Here you are provided with 3 options in which I will select “Use the new SharePoint user interface, and don’t ask me again”.  After clicking on OK, I am now presented with the same site utilising the default SharePoint 2010 theme.

We have now successfully upgraded one of our SharePoint 2010 content databases housing our main Intranet portal, albeit with some missing web parts and features.  So what’s next on the agenda?  Upgrading My Sites of course!  This will involve attaching and upgrading your Shared Service Provider (SSP) to upgrade your user profile information followed by upgrading the My Sites content database.  This process will be left for a future post.

I hope you have found this 2 part series useful and I am interested hear how many of you have attempted a SharePoint 2010 upgrade and your experiences.

Resources from TechNet

Determine Upgrade approach (SharePoint 2010)

Microsoft SharePoint 2010 Products Upgrade Approaches – Diagrams

Upgrading to SharePoint Server 2010

Preparing to upgrade to SharePoint 2010 Products

Attach databases and upgrade to SharePoint Server 2010

_______________________________________________________________

Articles in this series

1. Upgrading your Content DB to SharePoint 2010 – Part 1, The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Part 2, Database Attach method

1. Upgrading your Content DB to SharePoint 2010 –The preupgradecheck
2. Upgrading your Content DB to SharePoint 2010 – Using the Database Attach method

First and foremost, Microsoft have provided us with the pre-upgrade command line stsadm parameter switch in SharePoint 2007 Service Pack 2, which has been further updated with the latest October 2009 Cumulative Update (CU),. This will be our primary analysis and reporting tool providing us with invaluable information regarding your SharePoint 2007 farm and actions that may be required to be taken prior to upgrading to SharePoint 2010, so let’s begin our journey here.

Launch a Windows command prompt on your SharePoint Server and type the following stsadm command from the following directory;

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

stsadm.exe -o preupgradecheck

STSADM -o deactivatefeature -id 758a6fdf-005a-bcaa-0ea0-1d4931979fec -url http://intranet.georgekhalil.com -force

In addition to the STSADM command line tool, there are a couple of other tools that really assisted with the process of removing rogue features where the stsadm actually failed.  The first tool which is provided by Gilham Consulting , is the WssAnalyzeFeatures tool, which will assist in listing features against their GUID similar to that of the preupgrade report.

The second tool required as part of the removal process is the WssRemoveFeatureFromSite which will remove rogue features installed in your SharePoint farm where the stsadm –o deactivate feature might fail.  Eventually you would want the output of the WssAnalyzeFeatures command to display no problems.

So after re-installing or removing any rogue features and site definitions we should be ready to proceed with our SharePoint 2010 upgrade, taking into account that there were no other problematic areas that were outlined in the preupgrade check.

There are several other tools worth mentioning that also assisted with outputting information and configuration details of my farm and assisted with the SharePoint farm cleansing process.

The SharePoint Feature Administration and Clean Up Tool which you can download from the Codeplex site,  does a great job in listing Feature Definitions across Site Collections and Sub Webs and cleanly uninstalling them.  My favourite feature in this tool is its ability to locate any faulty features and then providing you with the ability to remove them from your entire farm.

Clicking on the Find Faulty Feature in Farm should hopefully return the following “No Faulty Feature was found” message.

SharePoint Manager 2007 (note there is already a SharePoint Manager 2010 available) can also be downloaded from the CodePlex Site and is a great tool for administrators and developers in providing an understanding of any SharePoint farm topology.

My last tool of choice is from Bamboo Solutions, namely the Bamboo SharePoint Analyzer.  Similar to that of SharePoint Manager 2007, this utility also does a great job is listing everything you need to know about your SharePoint environment and your entire farm topology.  This is also available as a free download and should be installed as part of any SharePoint Farm deployment.  These tools will also greatly assist in replicating your environment for your SharePoint 2010 deployment.

Hopefully I have provided you with a comprehensive list of tools and tips to assist you in getting your Content DB’s primed for your SharePoint 2010 upgrade.  In the next part of this series I will focus on the actual upgrade itself utilising the Database attach method, so stay tuned!

References:

Upgrading to SharePoint Server 2010 – TechNet

Run the pre-upgrade checker (SharePoint Server 2010) – TechNet

5 Reasons SharePoint 2010 PreUpgradeCheck is better than Prescan – SharePoint Joel

Preparing for Upgrade to 2010 Today – Part 1 Preupgradecheck – SharePoint Joel

Planning for SharePoint 2010 – Upgrade Planning Part 4 – Using preupgradecheck – Chandima.Net

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 Beta Service Applications and User Profile Service Synchronization

Now that you are up to speed, let’s begin by navigating to SharePoint 2010 Central Administration / Application Management. You will notice that the redesigned interface organises and categorises items in an orderly fashion, with a lot of familiarity with SharePoint 2007.

The first step in the process is creating your first Web Application to host our Site Collections.

Under the section Web Applications, click on Manage web applications.

On the new fluent ribbon UI, click on New.  (By the way, I think the ribbon UI is a welcome addition to the 2010 interface making it easier for administrators and end users to make decisions and change details within a couple of clicks).

The all so familiar Create New Web Application window appears albeit as a pop up window which does make navigation a lot nicer.

There are a couple of enhancements and improvements worth noting, with the first being the two types of authentication that you are provided with when creating your new web application, being Claims Based Authentication vs. Classic Mode Authentication. In summary, SharePoint 2010 is now “claims aware” making SharePoint a lot easier to work with systems such as Active Directory and providing single sign on for on-premises and cloud based applications across organisations. The following link provides a great overview on Claims Based Authentication and the role it will play within SharePoint 2010.

http://blogs.technet.com/ritaylor/archive/2009/06/03/claims-based-authentication-an-overview.aspx

Proceed and fill out the Create New Web Application Form. As a guide, I have provided sample answers below .

Authentication: Claims Based Authentication

IIS Web Site:

Create a new IIS web site

Name: SharePoint Intranet Portal (Always best practice to create a new IIS website for each new SharePoint Web Application.)

Port: 80

Host Header: Leave Blank or specify a preferred host header. (If you specify a host header, the alternate access mapping will be created for you automatically.  Please ensure that you also create the relevant A record in DNS.

Path: Leave default C:\inetpub\wwwroot\wss\VirtualDirectories\80 (This is usually determined by Port number and or Host Header Input)

Security Configuration

Allow Anonymous: No

Use Secure Sockets Layer (SSL): No

Identity Providers

Enable Windows Authentication: Negotiate (Kerberos or NTLM)

Sign in Page URL

Default Sign In Page

Public URL

Keep default Entry against your Default Zone.

Application Pool

Create new Application pool: SharePoint Intranet Portal (I have matched the pool name against my IIS website name for consistency, again it’s best practice to create a new application pool for each SharePoint Web Application that you create.

Database Name and Authentication

Specify your Database Server, Database Name and keep Windows authentication which is recommended.

Failover Server

This is a new feature in SharePoint 2010 providing you with the ability to specify a second SQL server that is participating in database mirroring, allowing you to easily failover if the primary SQL server fails. This is a welcome addition providing a means of high availability.

Service Application Connections:

Edit the following group of connections: default

Note, SharePoint 2010 allows you to connect a web application to all service applications available in a farm or a subset that you define.  This can be changed at any time.

Customer Experience Improvement Program

Enable Customer Experience Improvement Program: Yes or No

Click OK to initiate the creation process.

Click OK

Our new Web Application will now be listed along side our SharePoint Central Administration v4 Web Application under Central Administration/ Application Management / Manage web applications

We are now ready to create our first site collection. Navigate to Central Administration / Application Management / Create Site collections.

As you can see, the interface hasn’t changed at all from SharePoint 2007.

Ensure that the newly created Web Application is selected.

Enter a Title and Description. Under Template Selection I will click on the Collaboration Tab and select the trusty Team Site as this will be my starter site hierarchy for my development Intranet Portal.

Enter the Primary and Secondary Site collection administrators and then click OK.

That’s it. Our first site collection is up and running.

This is only the beginning of our journey.  In upcoming posts I will delve into the nitty gritty and get my hands dirty discussing the new features of SharePoint 2010.

This concludes our series on getting the basics of SharePoint 2010 up and running and will serve as a base for all future posts on introducing SharePoint 2010.  So stay tuned and be notified on upcoming posts by subscribing to my RSS feed.

______________________________________________________

Articles in this series;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

Service Applications is the new model adopted by Microsoft in SharePoint 2010 to replace the Shared Services Provider (SSP) model that was introduced in SharePoint Server (MOSS) 2007. Service Applications in SharePoint 2010 is aimed at allowing for greater flexibility over the legacy SSP model and is now incorporated into WSS 4 or commonly referred to as SharePoint Foundation 2010.  Some of the notable enhancements with Service Applications over SSP include the following;

• different sets of services can be associated with different web applications
• web applications can be configured to only use the services that they need
• publishing a service application allows for sharing across multiple server farms (applies to some services only)
• 3rd party integration into the service applications model is now possible
• There isn’t a separate site for service applications (i.e. accessible via Central Administration and not via a separate site as is the case with SSP in SharePoint Server 2007.

In part 1 of this series, we finished off with the installation of SharePoint 2010.  Upon completion of the installation, the Farm Configuration Wizard should launch automatically, however you can also invoke the same wizard by navigating to SharePoint Central Administration / Configuration Wizards.

Under farm configuration, click on Launch the Farm configuration wizard

As this is our first time in configuring the SharePoint Farm, click on “Walk me through the settings using this wizard” option and click Next.

The following screen provides you with the ability to set your Service Account.  It would be best practice to select “Create new Managed account”, however with all the issues around beta and service accounts I would recommend using your Domain Administrator account.  Remember, SharePoint 2010 is still in beta and should only be setup in a development environment for testing purposes.

A list of the service applications is also displayed below and I will keep the default services selected which is everything excluding the Lotus Notes Connector.

Click Next.  I’ve seen the following “Processing” screen a few times now with the SharePoint  2010 install and is very re-assuring if I must say.

You will be greeted with the Create Site Collection page in which we will Skip in this instance. I will be providing you with a step by step guide in creating your first Web Application and Site Collection in part 3 of this series which will follow shortly after this post. Stay tuned

This now completes the Farm Configuration Wizard which is a breeze I must say.  Below are all the services that are running by default.

Click Finish

If we now navigate to Central Administration / System Settings / Manage servers in this farm, you will notice that our Services Running in the farm has expanded to include the Application Services.

This concludes the first part of this article in getting SharePoint 2010 service applications up and running.  We will now focus our efforts in configuring our user profile service application.  Word of warning, there are elements below that are workarounds around potential issues you may encounter with the beta.  But if you follow my instructions, you should reach the final outcome, which is successfully importing your users.  Note:  Please ensure you read the rest of the article in its entirety before proceeding with your own configuration, as this will ensure you won’t need to double up in any step (you will know what I mean when you read on)

Let’s begin by navigating to SharePoint 2010 Central Administration / Application Management / Manage service applications / User Profile Service Application.

You will notice on the far right that our user and organization properties are present but our user profiles are currently non existent.

Under Synchronization, select Configure Synchronization Connections.

Click on Create New Connection

Enter the details as follows;

Connection Name: My Active Directory Domain
Type: Active Directory
Connection Settings: Specify a domain controller (type in the fully qualified domain name (fqdn) of your Active Directory Server) – Note: I had issues populating the containers when using the Auto discover method (details and error below)
Authentication Provider Type: Windows Authentication
Account name: Domain\Administrator
Password: *************

Click on Populate Containers which should enumerate your Active Directory Tree.  This is a welcome enhancement in SharePoint 2010 removing the need to type in the correct active directory lookup syntax.

Note from above: I actually needed to specify a domain controller. The Auto discover option above did not work for me and kept giving me the below error “The distinguished name contains invalid syntax “ when attempting to “Populate Containers”  I would be interested to know if others have encountered the same issue.

After selecting your container, click OK.

Now, the bugs begin. The page redirects back to the “Create New Connection” page but it’s blank!  I was actually able to reproduce this issue on 2 separate installs and farm configurations.

The issue lies with the Forefront Identity Manager (FIM) Services which I have listed as follows.  I launched Services under Windows 2008 R2 Administrative Tools on my SharePoint server to find the following 2 services in the following state.

• Forefront Identity Manager Service – Logon as Local System (Disabled)
• Forefront Identity Manager Synchronization Service – Log on as \ (Disabled)

The Microsoft SharePoint Team Blog goes in some detail regarding these services in which I have provided a link below as reference.

In order to fix our FIM services state we need to navigate to Central Administration / System Settings / Manage services on server. You will be presented with a list of your application services and you will notice that both the User Profile Service and User Profile Synchronisation Service are actually started (well in my case they were).

Click on Stop for both services and then start them again. This will fix the Forefront Identity service issues and you will notice that these will now be set to automatic with the correct logon permissions; We are now cooking with gas!

If your connection is still not listed under Synchronization Connections then you will need to re-create it as per the instructions provided above.  Yes! painful, but I guarantee it will work the second time, now that our FIM services have started correctly in Windows services.  As you can see from the below screen shot, I was eventually able to create my first Active Directory Connection.

We are now ready to click on Start Profile Synchronization!

Click on Start Incremental Synchronization.

Click OK.

It may look like that nothing is actually occurring but the synchronization process is actually happening in the background. To confirm that this is the case, if I click on Start Profile Synchronization soon after, I will receive the below popup message;

Note: This process took approximately 10 minutes for 8 users in my environment, but again this is beta. Hopefully things will speed up when SharePoint 2010 RTM’s.

Let’s now venture to Manage User Profiles;

You will be greeted with “There are no results to display” and no user profiles listed, (even though it specifies a total number of profiles being 8 in my case) .

This is another gotcha and it looks like things have changed here a little and you will now need to search for your users, as opposed to them automatically appearing.

We have now successfully completed our import of our Active Directory users into our user profile service application.  In the next article in this series I will provide you with the steps required to create your first Web Application and Site Collection.  This will provide us with a nice base to play around with, and begin exploring the plethora of goodies that are available with SharePoint 2010.

Be sure to add your own experiences in configuring the user profile service application below.

Stay tuned, the journey with SharePoint 2010 has only just begun.

References:

Path to User Profile Synchronization success in SharePoint 2010 Beta http://blogs.msdn.com/sharepoint/archive/2009/11/18/path-to-user-profile-synchronization-success-in-sharepoint-2010-beta.aspx

Configure Profile Synchronization (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee721049(office.14).aspx

______________________________________________________

Articles in this series;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 Service Applications and User Profile Synchronization
3. Configuring your first SharePoint 2010 Web Application and Site Collection

Before delving into the setup I will illustrate and summarize the proposed install for your testing and or development environment.  I will be utilizing this setup as my base platform for all future posts on SharePoint 2010 beta.  This is by no means based on any best practices for SharePoint 2010 (too early for that) but a means of sharing my experiences to date with the installation and configuration that might assist others in the process.

Environment

• 1 x Windows 2008 R2 Active Directory Domain Controller
• 1 x Windows 2008 R2 with SQL 2008 SP1 with Cumulative Update 2
• 1 x Windows 2008 R2 SharePoint 2010 Beta Server
• 1 x Exchange 2010 RTM
• 1 x Windows 7 running Office 2010 Beta

(Note that Windows 2008 R2, SharePoint 2010 and Exchange 2010 are 64 bit only)

Prerequisites

Please note that you will need to patch SQL with the latest cumulative updates for SQL 2008 or SQL 2005 depending on what version you will be running.  At the time of this writing, these are as follows

• SQL Server 2005 SP2 CU3 http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=23806
• SQL Server 2008 SP1 CU2 http://support.microsoft.com/kb/970315
• WCF Hotfix for Windows (KB976462) – To be installed after the SharePoint 2010 Preparation Tool has been run which installs the core prerequisites. http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=23806

The Install

Begin by downloading the actual SharePoint 2010 beta installer from http://technet.microsoft.com/en-au/evalcenter/ee388573.aspx and then launch the SharePoint 2010 setup program.  The below splash screen appears.

Click on Install software prerequisites;

Tip: Before proceeding with the SharePoint 2010 Preparation tool, ensure that the machine you are installing SharePoint 2010 on has Internet Access as the preparation tool will download any missing components.

Click Next

Accept the terms and conditions and click Next.

The Preparation tool proceeds to install the necessary components and prerequisites for the SharePoint 2010 beta.

Hopefully if all goes to plan, and remember this is still in beta, you should receive “installed successfully “confirmation against each of the required prerequisites.

Click Finish

We are now ready to install the WCF Hotfix for Windows (KB976462) which can be downloaded from the following Microsoft Connect site; http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=23806

Upon completion of the WCF Hotfix you will be required to Restart your server.

We can now proceed with the main Install by selecting Install SharePoint Server from the Installation Wizard splash screen.

Copy and paste one of the following product keys and click Continue once the validation process succeeds.

PKXTJ-DCM9D-6MM3V-G86P8-MJ8CY

BV7VC-RMR6B-26P6Y-BTQDG-DX2KQ

Accept the terms and conditions

Click Continue

You are now presented with two options, Standalone and Server Farm.

I will be selecting the Server Farm install option.  As tempted as one can be to select the all in one Standalone option, most SharePoint Admins and IT Pro’s will tell you otherwise.

Again, the dreaded Stand-alone option re-appears on the next screen.  As seasoned IT Pros we will be selecting “Complete”.

Click on the File Location tab and make any necessary Drive Adjustments.  I would leave the directory structure in tact.

Click on Install Now

Upon completion we are presented with the well-known “Run Configuration Wizard” that we have come to love or hate.  Leave “Run the SharePoint Products and Technologies Configuration Wizard now” check box selected.

After clicking close, you will be presented with the below welcome screen

Click Next

The following warning will appear regarding services being restarted throughout the process (identical to SharePoint 2007)

Click Yes

Click on Create a new server farm and click Next

The below “Specify Configuration Database Settings” page is displayed in which we will provide the necessary information including specifying the location of our SQL server, keeping or renaming the SharePoint Configuration database name and finally entering the necessary credentials for our database access account.

Tip: Recall from our prerequisites list earlier that you are required to have your SQL server running the latest cumulative updates.  These are as follows;

• SQL Server 2005 SP2 CU3
• SQL Server 2008 SP1 CU2

You will receive the below warning advising otherwise;

Click Next

The next screen is new in SharePoint 2010 beta and is requesting that a passphrase is entered.  As mentioned below, this designated passphrase is configured to ensure that no other SharePoint servers can join this farm unless the passphrase is provided.

Enter and confirm your passphrase and then click Next.

The next screen allows you to specify a specific port number or the ability to utilise the random one provided for your SharePoint Central Administration (CA) Web Application.  You are also presented with the authentication provider options for your CA Web Application in which it is usually best practice to utilise Kerberos for your SharePoint Web Sites, however NTLM will suffice for your SharePoint CA Web Application.

Click Next

The below summary screen is displayed.

Click Next.

The infamous performing configuration task screen is displayed.  All we can do now is cross our fingers and wait…

Warning:  It may sit there on the “Creating the configuration database” for a little while. Don’t be alarmed, this is normal and usually speeds up after the database creation.  You will eventually receive confirmation that the Configuration was successful.

After you Click OK, Your web browser should launch the SharePoint 2010 Central Administration page.

Tip: If you receive the below Windows Security Login popup dialog box, place the FQDN of your SharePoint 2010 CA server into Internet Explorer’s Local Intranet Zone.

After logging in you will be presented with the new SharePoint 2010 Central Administration page.

That’s all that is to it.  Before signing out, let’s venture into a couple of key areas to confirm the details of our farm configuration and then venture across to our SQL server and launch SQL Management Studio to determine what databases are created by default.

Let’s begin by navigating to Central Administration / System Settings / Manage servers in this farm

Let’s next launch SQL Management studio and browse to databases to see our SharePoint 2010 Databases listed in SQL.

We have successfully installed our first SharePoint 2010 server farm.  In part 2 of this series we will focus our efforts in creating our first ever SharePoint 2010 Web Application and Site Collection that will house our SharePoint 2010 portal.

I hope you have found this article of use.  Please feel free to extend and expand on your experiences in getting your SharePoint 2010 Beta up and running.  Please note, as this is still in Beta form there are bound to be a plethora of annoying bugs and workarounds.

References

Determine hardware and software requirements (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/cc262485(office.14).aspx

Jie Li’s GeekWorld http://technet.microsoft.com/en-au/evalcenter/ee388573.aspx

Deployment for SharePoint Server 2010 Beta http://technet.microsoft.com/en-us/library/cc262957(office.14).aspx

_________________________________________

______________________________________________________

Articles in this series;

1. Installing SharePoint 2010 Beta on a Windows 2008 R2 Server
2. Configuring SharePoint 2010 (Beta) Service Applications and User Profile Service Synchronization
3. Creating your first SharePoint 2010 Beta Web Application and Site Collection

1. Remote Desktop Services in Windows 2008 R2 -Part 1 – Installation
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway

RD Web Access is a component within Remote Desktop Services in Windows Server 2008 R2 which provides your remote users with the ability to access network published applications via Internet Explorer over SSL or commonly referred to as HTTPS.  This type of access breaks all barriers and restrictions where traditional VPN’s were IPSEC based or L2TP and usually required special software to be installed on the client machine which in itself required special configuration.  Not only was it cumbersome and problematic to setup for the non IT savvy, it usually caused potential problems for remote workers that were connected behind restricted Internet connections that only opened up a limited number of ports, namely HTTP and HTTPS.  This is where SSL based VPN’s such as RD Gateway (introduced in part 2 of this series) and RD Web Access come into play.

To recap, we went through the process of installing the necessary components for Remote Desktop Services including the RD Session Host and RD Web Access role services in part 1 of this series, with today’s focus on completing and fine tuning the configuration of RD Web Access and then shifting our focus on publishing remote applications in the latter half of this post.

So let’s begin by confirming the operation of the RD Web Access role by navigating to Start / Administrative Tools / Remote Desktop Services / Remote Web Access Configuration.

Because we are running a self-signed certificate on the IIS web site you will receive the usual Internet Explorer Certificate warning. It’s safe for us to click on continue to this website.

The below RD Web Access login screen will appear. Enter your administrative network credentials and then click on sign in.

The configuration screen will be displayed in which you have the option to select a Remote Desktop (RD) Connection Broker server or specify individual RemoteApp sources.

Let me provide you with a primer on the RD Connection Broker Server. Recall this was installed back in part 1 of this series as one of the role services installed for Remote Desktop Services. Formerly known as TS Session Broker, RD Connection Broker provides enhancements and benefits to the users experiences when connecting to an RD Host Server and are accessing RemoteApp and or Remote Desktop connections. These are listed below;

• Support for load balancing amongst Remote Desktop Servers located within a single farm
• Support for seamless user reconnection with farm based setups
• A new feature in Windows 2008 R2 is the ability to combine RemoteApp sources from different Remote Desktop Session Host servers that may potentially be housing different RemoteApp programs for compatibility and segregation reasons.
• Also a new feature in Windows 2008 R2 is the Direct integration with the newly introduced Virtual Desktop Infrastructure (VDI) – (to be covered in a future post.)

Considering that this is a basic single server Remote Desktop Host setup, we do not require to setup the RD Connection Broker, but I will outline the steps for convenience if you decide to go down this path;

1. The RD Connection Broker role service is required to be installed on a server. This could be on any server located on your network and does not necessarily need to be installed on a server running the Remote Desktop Host server or any of the other Remote Desktop Services Roles.

2. Add the RD Session Host servers that you would like to aggregate in your farm setup to the Session Broker Computers local group which is located on the RD Connection Broker server. (screen capture below)

3. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote Desktop Session Host Configuration and configure each RD Session Host Server that will participate in the farm to become a farm member in the RD Connection Broker. (highlighted below)

4. Lastly, you can utilise DNS round robin with the RD Connection Broker to provide load balancing. This is as simple as creating an addition A record in DNS to point each Remote Desktop Host Server that is participating in the farm to the farm name. The farm name is specified in the Remote Desktop Session Host Configuration and is common on all Remote Desktop Host Servers. Recall that this is located under Remote Desktop Session Host configuration / RD Connection Broker / Member of farm in RD Connection Broker’s properties.

The above steps have outlined the configuration of an RD Connection Broker server and the necessary steps required to configure your farm .  So going back to the RD Web Access Configuration screen we can either select “An RD Connection Broker server” as our source or individual RemoteApp sources (i.e. individual RD Host Servers).

As this is a single Remote Desktop Host setup, I will select one or more RemoteApp sources (which is selected by default), leave localhost as the source name as this is also our single  RD Host Server and click OK.

The web page will then redirect to the RemoteApp Programs screen which currently is not populated with any published applications …. but not for long.

This brings us to the second part of this article, Publishing RemoteApp Programs. Windows 2008 was the first version of Windows that provided us with the ability to publish individual applications to the Desktop and to TS Web Access or should we now say RD Web Access.

Quite simply, we can only publish applications that are installed on the Remote Desktop Host. Installing client applications on a Terminal Server is not the same as installing on a client computer and to ensure Remote Desktop compatibility it is best practice to still utilise the “Install Application on Remote Desktop” mini wizard provided. This is to ensure that our applications are installed utilising RD Install mode which configures the correct registry entries for a multi user Remote Desktop environment. You can also utilise Windows command prompt to achieve the same;

Change user / install – prior to running setup.exe of the application

Change user /execute  – after the application installation has completed.

For simplicity, you can access the wizard via Control Panel / Programs / Install Application on Remote Desktop.

This will initiate the wizard.

Click Next, complete the installation, and then click on Finish. Let’s install Office 2007 as our first client application on the Remote Desktop Host.

After installing Office 2007 utilising RD install mode, we now have our first application to publish to RD Web Access and to a Remote Computer desktop such as Windows 7. Lets start with the former first. Navigate to Start / Administrative Tools / Remote Desktop Services / Remote App Manager.

Under the Actions pane, click on Add RemoteApp Programs.

This will invoke the RemoteApp Wizard.

Click Next.

Choose the application that you would like to publish. I will select Microsoft Office Word 2007 in this example. Before clicking on next, let’s venture into the properties area as there is an enhancement made to Windows 2008 R2 over Windows 2008.

The first tab (properties) as you will see is identical to that provided in Windows 2008 with the ability to change the icon, provide additional command line arguments and a checkbox allowing us to make this published application available through RD Web Access.

The second tab (User Assignment) is new and a welcome enhancement to Windows 2008 R2 allowing us to specify users and or groups whom you want the published application to be visible to.

I will keep All authenticated domain users ticked and click OK.

Click Next to proceed with the wizard.

You will then be presented with the below summary of settings.

Click Finish.

We have now published our first RemoteApp to RD Web Access.

If I now navigate to the RD Web Access URL from any internal client computer, usually in the form of  https://servername/RDweb and login, our Microsoft Office 2007 icon will now be listed providing us with the ability to now launch published application singularly via a secure web interface.

In addition to publishing RemoteApp Programs to RD Web Access, we  are also provided with the ability to publish applications via a Windows Installer Package or via the creation of an .rdp file which both can be assigned to Remote Computers running Windows 7 etc.

Quite simply, right click on the Microsoft Office Word 2007 under RemoteApp Programs within RemoteApp Manager and select either Create .rdp File or Create Windows Installer Package. You can also initiate both wizards under Actions on the right navigation pane. Both have advantages and disadvantages with the .rdp file providing you with flexibility in the distribution method in deploying applications to remote users by providing them with a single .rdp file, whereas the Windows Installer Package is more geared towards Group Policy Software installation with added benefits in specifying shortcuts locations such as specifying that the shortcut icon will appear on client computers Desktop or Start Menu Folder.

This ends the series on Remote Desktop Services. This is by no means an exhaustive complex setup but it gives you a taste of what is possible with the technology and how far it has come since the early days of Windows NT. Every setup will be different and even though I have installed all of the roles on a single server, depending on the size of your organization and deployment these can be easily split across multiple servers with farm configurations and so forth to accommodate for larger number of users.

This article has not gone into great depth or detail with regards to securing your RD Gateway and RD Web Access with trusted 3rd Party Certification Authority Certificates such as those provided by GoDaddy and Verisign, nor have we discussed potentially publishing both RD Web Access and RD Gateway using a reverse proxy firewall such as Microsoft’s Internet and Acceleration Server (ISA) 2006 and the recently announced Forefront Threat Management Gateway (TMG).  Expect to see future articles on this topic.

Well, I hope you enjoyed this series and please feel free to comment about your experiences or questions you may have.  As always, you can follow me on Twitter and or subscribe to my feed.

Resources

Remote Desktop Connection Broker- What’s New; http://technet.microsoft.com/en-us/library/dd560675(WS.10).aspx
Remote Desktop Connection Broker; http://technet.microsoft.com/en-us/library/cc771419.aspx
Remote Desktop Web Access; http://technet.microsoft.com/en-us/library/cc731923.aspx
RemoteApp and Desktop Connection – What’s New; http://technet.microsoft.com/en-us/library/dd560650(WS.10).aspx
RemoteApp Manager; http://technet.microsoft.com/en-us/library/cc755261.aspx

____________________________________

Articles in this series;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 – Installation
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
3. Remote Desktop Services in Windows 2008 R2 – Part 3 – RD Web Access & RemoteApp

SharePoint 2010 came out of hiding during the SharePoint 2009 conference in Las Vegas several weeks ago and those who were lucky to attend were privy to hands on sessions and a plethora of seminars.  Well today, Microsoft have done a great job with providing Developers and  IT pros with an abundant amount of information regarding their latest release of SharePoint and in my own opinion are way ahead of where they were during SharePoint 2007 product’s release.

I will leave you with links to some resources from the  Microsoft TechNet site that will assist you with knowing as much as possible about this great framework.  I am sure the amount of resources made available will expand and extend as time goes by and as the product reaches final release and beyond.

For me, It’s download time baby and I can’t wait to get my hands dirty with the product I have come to love over the years.  Expect to see an abundant amount of blog posts sharing my administration and end user experiences of the product.

SharePoint 2010 Resources

SharePoint Server 2010 Beta TechCenter
SharePoint Foundation 2010 Beta TechCenter
Installation and Deployment Resource Center
Downloadable Evaluation guide for SharePoint Server 2010 (for IT Pros)
Microsoft SharePoint Product Team Blog
SharePoint 2010 (Beta) Developer Center

SharePoint 2010 Upgrade Models

Upgrade and Migration Resource Center for SharePoint Server 2010 (Beta)
Upgrade and Migration Resource Center for SharePoint Foundation 2010 (Beta)
What’s new in upgrade (SharePoint Server 2010)
Upgrade process overview (SharePoint Server 2010)
Determine upgrade approach (SharePoint Server 2010)
Use a trial upgrade to find potential issues (SharePoint Server 2010)
Microsoft SharePoint Server 2010 Upgrade Planning
Microsoft SharePoint Server 2010 Upgrade Approaches
Microsoft SharePoint Server 2010 — Test Your Upgrade Process
Microsoft SharePoint Server 2010 — Services Upgrade

SharePoint 2010 Product Details

What’s New in SharePoint Server 2010
Topologies for SharePoint Server 2010
Search Technologies for SharePoint 2010 Products
Search Environment Planning for Microsoft SharePoint Server 2010
Services in SharePoint 2010 Products

There are a number of prerequisites that are required in order for the RD Gateway to function and these were all setup in part 1 of this series. For reference I have listed these below;

• Remote procedure call (RPC) over HTTP Proxy
• Internet Information Services

Let’s begin by navigating to All Programs / Administrative Tools / Remote Desktop Services / Remote Desktop Gateway Manager. You will be presented with the below screen.

In the left navigation pane of your RD Gateway Manager MMC console, click on your server and select properties under Actions. We will now go through each tab under the server properties and make any necessary configuration changes.  Let’s refer to this process as post wizard configuration.

Under the General Tab, we are provided with the ability to configure the maximum number of connections that are allowed to connect to this RD Gateway. If you are concerned with server performance, we can set a hard limit of allowed simultaneous connections. We can also disable new connections if we are performing scheduled maintenance on our server.

The next tab allows us to secure the RD Gateway by using an SSL certificate.  We can create a self-signed certificate (recall that this was completed during the initial install wizard in part 1 of this series), select an existing certificate that is located on the server under Certificates / Personal store or Import a certificate that we have requested via a 3^rd Party Certification Authority (CA) or utilising an internal CA. It is deemed best practice to utilise a 3^rd party CA that participates in the Microsoft Root Certification Members Programme alleviating the headache that is usually involved in exporting the root certificate, distributing them to your end users and then providing them with instructions on how to import them into their local machines. Utilising a self-signed certificate is usually reserved for testing purposes only, and not in a production environment, however it will suffice in this step by step guide.

The third tab introduces the RD CAP Store and provides us with the ability to utilise our local server running Network Policy Server (NPS) or the ability to specify a central server that is already configured and running NPS.  This was also initially configured during the installation wizard of our Remote Desktop Services role in part 1.

The next tab, Server Farm, allows us to specify farm members for the RD Gateway. As a minimum we need to Add this RD Gateway server below as follows.  You do so by entering the fully qualified domain name of the server and clicking on Add.  It will then add it below under Remote Desktop Gateway server farm status as per the below screen capture.

You will notice the above warning regarding the registry not being updated. This warning will disappear and the status will change to OK after clicking on Apply.

The next tab allows you to select or deselect events that you would wish to log. These corresponding events are stored in Event Viewer under Application and Services Logs\Microsoft\Windows\Terminal Services-Gateway\.  By default, all items under the Auditing tab are selected to be captured and logged.  The below screen capture is an example of the TerminalServices – Gateway Event Viewer on our Windows 2008 R2 server.

SSL bridging is next and is required to be configured if you are utilizing Microsoft ISA Server to further secure the RD Gateway.  Microsoft ISA Server is a great application level firewall which offers reverse proxy and can be configured to work hand in hand in providing secure access over SSL.

The last tab in the RD Gateway properties is Messaging which was not present in Windows 2008 TS Gateway. This is a welcome addition for administrators to utilise when pre-planning for system maintenance and wanting to advise users with a global system notification, and the also providing the ability to set a logon message such as the company’s logon policy.

The first area within the Messaging tab is the ability to set a timed system message with the ability to set a start date/time and end date/time.

When a user logs in via the RD Gateway, they will be presented with the following message that we configured above;

The second area under messaging allows you to specify a message such as your company’s logon policy that will appear each time a user logs into the RD Gateway remote computer. This is simply a text file with the contents within.

The below similar notice is what will appear when logging on to your Remote Desktop Host via the RD Gateway

You will notice that the system will not continue to login (the OK button is dimmed) unless you accept the terms of this policy.

The last option allows you to specify that connections to the Remote Desktop Host via the RD Gateway will be restricted to clients that support RD Gateway messaging which is anything greater than Remote Desktop Client version 7.

Now prior to connecting to the RD Gateway and testing our setup, we will need to export the self-signed SSL certificate located on the RD Gateway and install it on our client computer that we will be connecting from. The easiest way to accomplish this is to open the Certificates MMC snap-in, locate the certificate from the Personal / Certificates store, and right click, All Tasks / Export.

This will invoke the below Certificate Export Wizard.

Click Next

Select Yes, export the private key.

Click Next.

Select, Include all certificates in the certificate path if possible

Click Next. Type and confirm a password and then click Next again.

Specify a name and location to export the pfx certificate file.

Click Next and then Finish.

We can now copy or email the exported certificate to our end users who will then install the certificate to their local personal store. This can be easily achieved by double clicking on the exported certificate and invoking the Certificate Import Wizard. Please ensure that when you come to the Certificate Store section of the Import Wizard that you select “Place all certificates in the following store” and select “Trusted Root Certification Authorities”.

Now that we have successfully imported the root self signed certificate authority, we can now test our setup and login to our remote computer via the RD Gateway. Before we begin, you need to ensure that you are running the latest Remote Desktop Connection client which is version 7. This version is already included with Windows 7 and is made available for download to Windows Vista SP1 and SP2 clients and to Windows XP SP3 clients. This can be downloaded from the Microsoft Support site; http://support.microsoft.com/kb/969084

The above article also provides you with a comprehensive list of new features and their explanations that are only possible with RDC 7 and Windows 2008 R2.  I have listed these below for convenience;

• Web Single Sign-On (SSO) and Web forms-based authentication
• Access to personal virtual desktops by using RD Connection Broker
• Access to virtual desktop pools by using RD Connection Broker
• Status & disconnect system tray icon
• RD Gateway-based device redirection enforcement
• RD Gateway system and logon messages
• RD Gateway background authorization & authentication
• NAP remediation with RD Gateway
• Windows Media Player redirection
• Bidirectional audio
• Multiple monitor support
• Enhanced video playback

From a client machine running RDC 7, navigate to Start / All Programs / Accessories / Remote Desktop Connection or just search for mstsc.

Click Options and then navigate to the advanced tab.

Click Settings and then select Use these RD Gateway server settings:

Enter your server name and logon method details as follows;

Then click OK. Ensure that Bypass RD Gateway server for local addresses is deselected. Navigate back to the General Tab and enter the Computer and User name details and then click Connect when ready.

The following Windows Security popup will appear asking you to authenticate prior to launching a full remote desktop session.

After entering your credentials and clicking OK, You will be prompted to accept the login policy that we specified earlier under the Messaging tab of the RD Gateway properties.

So that’s it, we are now logged in to the Remote Desktop Host via the RD Gateway. We can confirm this by clicking on the spanner located on the top toolbar which will output the Remote Computer and Gateway Server that we are connected to. It also states that the connection to the remote computer was made using a Remote Desktop Gateway server.

That’s it for now. In our next and final article I will discuss Remote Desktop (RD) Web Access and the publishing of Remote Desktop Applications, so stay tuned.

_________________________________________

Articles in this series;

1. Remote Desktop Services in Windows 2008 R2 -Part 1 , Installation and Configuration
2. Remote Desktop Services in Windows 2008 R2 – Part 2 – RD Gateway
3. Remote Desktop Services in Windows 2008 R2 – Part 3 – RD Web Access & RemoteApp