Ask the Performance Team

Happy Friday AskPerf!  I'm sure you've already surmised by the title of the post that today's topic is a somewhat bittersweet one.

It is said that all good things must come to an end.  In that same vein, the one constant about working at Microsoft is that change is inevitable.  Over the last three (well, almost three!) years, it has been my privilege and honor to administer and write content for the AskPerf blog.  I have had a tremendous amount of fun doing it, and I’ve learned a great deal.  One of the things I have particularly enjoyed is watching the comments section related to some of our posts take on a life of their own and become truly discussion-oriented.  Nothing about AskPerf has been more special than watching the AskPerf community engage in open, honest and respectful debate and also being supportive of one another when requests for assistance are made.  This is a very special group of readers.  However, it is time for me to say farewell to AskPerf.

I have recently accepted a position as a Program Manager within our Product Quality and Online group.  Specifically, I will be working within the Software+Services space.  The oppportunity to step into a new technical arena in this role is exciting for me - both personally and professionally.  And so, it is time to turn the keys to AskPerf over to someone else to keep the blog going strong.  That someone is Tim Newton (of Demystifying /3GB fame among others).  Tim has authored several articles since the launch of AskPerf.  In March 2008, Tim stepped up to take on the responsibility of being a co-owner of the blog.  The transition, therefore, should be virtually seamless.

I will continue to follow AskPerf with great interest, but it’s the time has come for me to turn the reins over to Tim.  I am going to step back from work-related blogging for a little while as I get ramped up in my new role.  I haven't really worked on any blogging for myself over the last few years, so I will also be working on getting my personal blog kicked off over the course of the next few weeks, and also helping my daughter get started on her own blog.

Believe me when I say that the AskPerf blog is a huge group effort!  I owe an enormous debt of gratitude to all of the people on the Performance team who have contributed articles and ideas, spent countless hours doing research and problem reproduction, as well as proofreading and editing post submissions.  Without their tireless efforts we would not have been able to generate the amount of content we have - especially for our two Launch Series on Windows Server 2008 and Windows 7 / Windows Server 2008 R2.  I also would like to extend my deepest thanks to the many folks in other parts of Microsoft Commerical Technical Support, as well as all our friends in the Product Group, Premier Field Engineering, Global Escalation Services, Product Quality and Online and of course the many Technical Account Managers who have been absolutely amazing in terms of offering guidance, feedback and support.

Last, but my no means least in any way I would like to thank YOU – the AskPerf readers.  Your constant support and candid feedback has been invaluable over the last (almost) 3 years. Without you, there’s no way we would be where we are today.  I wish each of you the very best and look forward to our paths crossing again in the future.

THANK YOU!!

Good morning folks!  Sorry that today’s post is a little later than usual.  We’ve been tracking an issue related to Microsoft Security Bulletin MS09-065 (KB Article 969947) on Windows XP.  You may notice odd behavior including system hangs, bugchecks or even blank desktops during RDP sessions following the installation of this patch.  Customers have reported that removing the patch restores system stability.  The fix for this issue is fairly straightforward:

• Reboot the system into safe mode
• From within Add/Remove Programs, uninstall the patch.  The patch will be listed as Security Update for Windows XP (KB969947)
• Restart the system in normal mode

At this point, the steps within the KB Article indicate that you should remove your video card drivers / management suite and then re-install the patch before updating your video drivers to the latest version provided by the manufacturer.  There have been some customers who have updated the video card drivers first and then re-applied the patch successfully.  In either case, the key is to ensure that you get your video card drivers updated to avoid stability issues with this patch.

That’s all for today – a short post, but one that we wanted to get out there since we are seeing quite a few customer incidents on this.  Friday’s post will be … something different.  Until next time …

- CC Hameed

Share this post :

Happy Friday AskPerf!  We’ve had a few questions in the past about guidelines for application design in a faster computing environment.  Now, I make absolutely no claims whatsoever to being any sort of a code guru, and so I wasn’t about to try to pass myself off as an expert in that area!  Thankfully, after doing some research, it turns out that a fellow Microsoft Blogger (Rick Vacik) has already done so!

Below are some excerpts from Rick’s three-part series on Designing Applications for High Performance.

Designing Applications for High Performance – Part I: Now that processors won’t be getting dramatically faster each year, application developers must learn how to design their applications for scalability and efficiency on multiple processor systems.  I have spent the last 20 years in SQL Server development and the Windows Server Performance Group looking into multi-processor performance and scalability problems.  Over the years, I have encountered a number of recurring patterns that I would like to get designers to avoid.  In this three part series, I will go over these inefficiencies and provide suggestions to avoid them in order to improve application scalability and efficiency.  The guidelines are oriented towards server applications, but the basic principles apply to all applications.

Designing Applications for High Performance – Part II: The second part of this series covers Data Structures and Locks.  I will provide general guidance on which data structures to use under certain circumstances and how to use locks without having a negative impact on performance.  Finally, there will be examples covering common problems/solutions and a simple cookbook detailing functional requirements and recommendations when using data structures and locks.

Designing Applications for High Performance – Part III: The third, and final, part of this series covers I/O Completions and Memory Management techniques.  I will go through the different ways to handle I/O completions with some recommendations and optimizations introduced in Vista and later releases of Windows.  I will also cover tradeoffs associated with designing single and multiple process applications.  Finally, I will go through memory fragmentation, heap management, and provide a list of the new and expanded NUMA topology APIs.

Enjoy your weekend everyone!  Until next time …

- CC Hameed

Share this post :

Good morning all – today’s post is a very brief one regarding new announcements concerning Remote Desktop Services.  The original announcements were made on the Remote Desktop ServicesTeam blog.

• RDS CAL Single Pack now available in Retail channel – Remote Desktop Client Access Licenses (CAL’s) were previously only sold in packs of 5 and 20.  There was no option to buy a single CAL.  In response to customer request, Single CAL Packs are now available for Windows Server 2008 and Windows Server 2008 R2 for both Per-user and Per-device license types
• Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2 – Remote Desktop Connection 7.0 was released on October 28th.  KB969084 provides a detailed description of available functionality and provides links to the download package.  For details on the functionality of RDC 7.0, please refer to this post on the Remote Desktop Services team blog.  One side note – if you previously installed the fix outlined in KB968358, installing RDC 7.0 will undo the fix.  Stay tuned for updates on when this is corrected
• Remote Desktop Load Simulation Toolset – This toolset can be used to create and measure load when using Remote Desktop Services.  This toolset will be useful when conducting your own scalability testing.  The toolset and the accompanying documentation can be downloaded from the Download Center on Microsoft.com

Until next time …

- CC Hameed

Share this post :

Happy Friday AskPerf!  One of our Technical Account Managers pinged me a few weeks ago and asked if I could put together something on how to do a server baseline.  After thinking about how best to do this for a while, I realized that trying to create a one-stop shop for server performance baselines goes well beyond a blog post and into the realms of entire books!  But, that doesn’t mean that we don’t have some good tips for you …

So, to start with – what exactly is a baseline?  Simply put, a baseline is a picture of how your server normally operates.  Having a baseline is incredibly useful you’re doing capacity planning, performance-related troubleshooting, or even disaster recovery planning.  Now, a good server baseline encompasses far more than just running a Performance Monitor for a couple of hours and then calling it a day.  All the tips below can be implemented using Microsoft tools that either come with the server or are free to download.  So, let’s get started …

10. One Baseline simply won’t do:  OK, you’re already thinking … what?  What are you talking about?  Server Performance is affected by time.  Think about it – Monday mornings (well, probably every morning) at 9:00 am are probably when your domain controllers are busiest trying to resolve authentication requests from users logging in after the weekend.  File servers have probably been relatively dormant over the weekend as well.  Terminal Servers – well, that goes without saying … doesn’t it?  By the same token, getting a baseline at the end of the day isn’t a bad idea either.  We just talked about logon / logoff issues on Terminal Servers due to profile issues.  Do the same “slowness” problems occur on Monday morning and Friday afternoon?  You’ll definitely want to get an understanding of server performance during those peak times, as well as at different times during the day – and even during your business cycle (such as year-end processing).  Which brings me to …

9. You’re a 24x7 shop.  Backups and Data Analysis Jobs count too:  We’ll often hear from customers reporting that backups are “slow”.  Well, “slow” is a relative term.  If you only capture your baseline data during business hours, then you may be missing out on rich data gathering opportunities during off-hours when – let’s face it, some of your most important business functions take place.  That’s money time when it comes time to do your Disaster Recovery exercise.  No good backups means no Disaster Recovery capabilities.  In addition, if you’re responsible for servers that do after-hours data processing (SQL Servers primarily is what I’m thinking of here), then you’ll definitely want to get an idea of how long those jobs take to run.  Make sure you pay just as much attention to what happens when you’re not in the building as you do when you are.  Remember, there are lots of variables when it comes to performance, and thus the importance of …

8. Gathering trending data:  I mentioned getting baseline information at different times of the day – as part of your baseline process, consider taking longer performance monitor captures with longer intervals so that you can see the complete picture over a number of days etc.  This is the type of data that really carries weight when it’s time to go ask for more money as part of your capacity planning!  And that provides a great segue into the fact that …

7. Your baseline is more than just your server: OK, given that this is a post about server baselines, you’re probably wondering where I’m going with this.  Just as you need to account for different time slices, and trending data, you also have to account for your entire infrastructure.  Be holistic in your baseline captures.  If you have SAN’s, have the SAN vendor review the performance of their hardware as well as LUN configuration on a regular basis – not just when something isn’t acting quite right.  In addition, keep an eye on your network health.  Sometimes issues that seem to be server performance problems aren’t really server-side problems.  Which is why we have to remember that …

6. Applications need love too: We’ve discussed hardware, the network and the operating system.  But, applications sometimes have their own performance quirks.  If the application is one that was developed in-house, then you can get your hands on the developers (usually) and get some idea of how their application should perform.  For 3rd party products this may be a little more tricky, but there is no harm in calling up your ISV and trying to get some idea of acceptable application performance – especially when you’re talking about n-tier type applications with lots of complexity.  Knowing how an application should be performing versus what it’s doing in your environment can help you identify potential issues before they become all-night / all-weekend conference calls during year-end processing.  Part of being successful with the last three or four things I’ve mentioned is that you’ll need to …

5. Be Inquisitive!  Asking questions isn’t a bad thing:  There’s a saying that “the only dumb question is the one you don’t ask”.  Whether you’re an IT Admin responsible for the operating system, an application developer, a DBA or the Network guru, more knowledge is not a bad thing.  Before I started at Microsoft I worked in a very compartmentalized IT environment.  It was “the way things had always been done” – namely that the network guys didn’t readily share information with the OS team, who didn’t always collaborate well with the application implementers … well, you can see where this is going.  Not only did this mean that no-one really had a clear picture of what was going on even in a general sense, but if (when!) something went wrong, it took twice as long to make progress because either no-one knew who to call, or how to explain the problem in terms that made sense to other groups.  Sharing knowledge doesn’t mean that you’re sacrificing job security – you’re not turning over the keys to the kingdom!  It means that you’re collaborating and becoming a cohesive team!  Beyond the obvious technical knowledge that passes back and forth, the human relationships that you forge will make your life easier!  And in terms of holistic performance monitoring and baselines, it always helps to know just who to go.  OK, let me hop off my soapbox now (yes, this is one of my biggest peeves about IT environments!) and move on to why …

4. Documentation matters:  I’m sure everyone has a plethora of horror stories about poor / non-existent documentation and the resultant nightmares.  In complex enterprise environments, documentation reigns supreme.  When you’re talking about historical performance and capacity planning in particular, it’s all about the numbers.  If you can’t prove that you need something, the odds are you’re not going to get it.  Keep your historical baselines, and make sure you can put your hands on your change management history.  That’s almost Troubleshooting 101 - “What changed?” – but you’d be amazed at how many folks can’t find out how / why / when something changed in their environment.  And that’s when we’re troubleshooting – now add Audit and Disaster Recovery to your list of considerations and if someone isn’t already keeping tabs on … well, everything – then it’s time to start.  Now, if you have all of this all set up and ready to go, let’s turn our attention to why …

3. Problems aren’t always problems:  Deep, huh?  But, look at it from this perspective - server performance doesn’t just get worse without a reason.  The underlying causes may certainly be problems – bad hardware, problematic application update, non-optimized code etc.  But – problems are also opportunities.  Slow performance may also be caused by excessive load, slower hardware (different from bad hardware!), and again – non-optimized application code.  If you can provide evidence as to how performance is relatively poorer when compared to weeks, months or even years ago then you’ve provided a business reason for that server upgrade or application review - especially if you …

2. Don’t take the humans out of the loop:  I remember when the movie WarGames came out many, many years ago (and yes, I know I’ve just dated myself!).  One of the most telling lines in that movie was when someone said, “Take the men out of the loop”.  Movies like The Matrix and The Terminator were built off that particular sentiment!  There are plenty of tools out there that can monitor your servers and tell you when something’s wrong.  What they can’t necessarily do is tell you WHY.  Your monitoring software can’t intuitively make the connection between your frontend web server being slow thanks to caused by your middle-tier server not processing requests quickly which was caused by network latency due to slow authentication that was caused by the domain controller being overworked and trying to satisfy all of the LDAP requests caused by the guys doing a complete Active Directory dump as part of their server migration project.  It takes “the little gray cells” (as Hercule Poirot was so fond of saying) to put the entire puzzle together.  And last, but by no means least, that means you have to …

1. Keep it FRESH!:  I can’t stress this one enough.  That server baseline you took two years ago may not be of too much value today.  A number of different things have undoubtedly changed – application updates, network updates security patches, increased load, updated drivers.  All of these things contribute to subtle (and sometimes not so subtle) variances in your server’s performance.  For your mission-critical servers, you should be staying on top of your server’s performance – every minute that the server isn’t responding is a minute you might not be processing a sale, or closing a deal.

OK – that’s it for today’s post.  Quirky?  Perhaps.  But hopefully there are some nuggets here that can help you in your IT Adventures.  I’ll go over some standard Performance Monitor counters and how you can use them as while doing your baselines in a future post.  Until next time …

- CC Hameed

Share this post :

Welcome back AskPerf!  After our Windows 7 / Windows Server 2008 R2 Launch Series, it’s time to get back to business as usual.  Before our series I wrote a post touching on User Profile issues on Terminal Servers.  At the end of that post, I promised we’d come back and discuss some things you can do to speed up logons.  So, without further ado, let’s dive right in …

One of the most dreaded calls for Helpdesk staff is, “It’s taking a really long time to log on.  Can you fix it?”  When the problem is restricted to just one desktop, the problem is fairly manageable.  However, when the problem exists on a Terminal Server, the situations become a bit more complex because of the number of variables involved.  One of the unwanted side effects of slow logons on a Terminal Server is that users become reluctant to ever log off!  Beyond the additional system overhead of the idle sessions, there are other possible unwanted consequences.  Users with idle sessions may have inadvertently left files open in their session that are needed by other users (think shared Excel spreadsheets etc).  Since the session is still open (but idle), the files are locked.

Obviously you can set up policies to disconnect or terminate idle sessions after a certain amount of inactivity (and you should do so anyways), but that doesn’t always make for the best user experience (especially if you get over-zealous)!  If you can address the slow logon issues, thereby improving the user experience, users are more likely to log off, knowing that getting back into a session is not a painful experience.

We’ve already discussed how Folder Redirection can help you in terms of providing a consistent user experience, but they can also help speed up logon and logoff times.  Some other things to look at include using Group Policy to:

• Cache roaming profiles
• Use small profiles by setting a limit on the size of a user profile
• Delete unused cached profiles

Let’s talk about each of these, beginning with Roaming Profiles.  Terminal Servers normally attempt to retrieve roaming profiles from the central location where the profiles are stored.  If you have a network with slow links (or high latency links) between the Terminal Server and the Profile server, this can cause significant delays in logging on.  If the users were able to log on with a locally cached copy of the profile when the network connection between the Terminal Server and Profile slow was slow or unreliable then that can provide some relief.  One thing to note is that if you do cache the profile on the Terminal Server, that cached copy is only used if the original roaming profile is not available.  Now, there is a tradeoff for caching the profiles – namely hard disk space.  One definite caveat is that new users may not be able to log on if the space allocated to cached profiles gets filled up.  In addition, cached profiles that are not being used, should be removed to free up disk space.  On Windows Server 2003 systems, you can use the User Profile Deletion Utility (see the link below for the download location).  Use this utility as opposed to simply removing the files from Windows Explorer.  If you use Windows Explorer to remove the files, the registry information for those profiles is not deleted.  You can also use group policies on the terminal servers to delete profiles that have not been used in a specified amount of time (we’ll go over this in a second).

Moving on to profile sizes, one of the biggest problems that we see is that profiles have gotten bloated.  Remember that when a user logs on to the terminal server, their roaming profile has to be copied to that server, and then when they log off, the profile has to be copied back to the central network location.  Writing profiles back to the storage space does not just involve the delta between the starting profile and the ending profile – but in effect the entire profile.   If you don’t have folder redirection enabled for the user folders like Documents, Pictures etc. think about what might happen if a user saved 15GB of data into his Documents folder.  This user might log on and have to go to lunch before his profile is copied down.  Now expand the scenario to 30 users – and everyone tries to log on right when they come in at 9:00 AM.  Your network bandwidth would start to disappear fairly rapidly.  By using a combination of folder redirection (to prevent profile bloat and slow logon / logoff times) and group policies to limit the size of the roaming profile you can help to optimize the user experience.  The policy setting is located under User Configuration\Administrative Templates\System\User Profiles, and is called Limit Profile Size.  If you are combining this setting with folder redirection, you’ll want to take note of the size of the NTUSER.DAT file when setting your group policy setting.

OK – getting back to those cached profiles, I mentioned the User Profile Deletion utility above to remove old cached profiles.  But, you can perform the same sort of management via Group Policy.  There are two settings to be aware of (both under Computer Configuration\Administrative Templates\System\User Profiles):

• Delete Cached Copies of Roaming Profiles:  If you enable this, then the cached copy of a user’s roaming profile is deleted as soon as they log off.  However, since the cached profile does provide a fallback mechanism in the event that the user can’t get to their roaming profile, the user will get a temporary profile in this scenario – and any changes that they make to the profile will not be saved
• Delete User Profiles Older than a Specified Number of Days on System Restart: If you enable this setting, then cached profiles that are older than the threshold that you specify are deleted.  But – there is a caveat – the deletion only occurs at system restart.  So, if you don’t reboot your terminal servers regularly, then this setting might not help you out

OK – that will do it for today’s post.  As always, please test any changes in a non-production environment to gauge their impact and usefulness before you go live!  Until next time …

Additional Resources:

• Download: User Profile Deletion Utility (Delprof.exe)

- CC Hameed

Share this post :

That’s right folks!  It’s October 22nd – the big day is finally here!  Over the last twenty-one days, we’ve touched on a number of different features of Windows 7 and Windows Server 2008 R2.  We hope you’ve enjoyed our Launch Series.  Don’t fret – we have plenty more to write about regarding both operating systems.

We are launching some tools and resources to help customers upgrade to Windows 7 – the Windows 7 Upgrade Advisor and the Window 7 Compatibility Center.  Both tools are available at the Windows Compatibility Center.  The Windows 7 Upgrade Advisor scans your PC to see if it’s ready for Windows 7.  It checks to see if your PC meets the system requirements, lets you know if your processor is capable of running 64-bit versions of Windows 7 and gives guidance on your upgrade options.  It also tells you about any known compatibility issues with the most commonly installed software programs and devices connected to your PC.  If an issue can be resolved, it suggests next steps for you to take before installing Windows 7.  The Windows 7 Compatibility Center helps you easily check the compatibility of thousands of devices and software programs for 32-bit or 64-bit versions of Windows 7.  Usually, you won’t need to do anything to ensure compatibility.  If you do, the site goes beyond just telling you what will or will not work. It also provides links to drivers and software updates to help get your PC running with the latest software.  For more information, check out the Windows 7 Team Blog.

We are also launching an exciting new online competition called 7 Ways to Change the World and we need your help!  The competition encourages people to create a two minute video explaining how they believe a Windows PC could help a nonprofit make a greater impact.  It could be helping a food bank manage their inventory or helping to deliver after school care for kids, the possibilities are endless!  There will be 7 winners, and each person who submits a winning entry will receive a new PC with Windows 7 and a $7,000 grant for their chosen nonprofit organization.  The competition runs from October 21st until November 11th.  Each day from November 16th until November 24th we will announce one of the 7 winners.  You can get the latest news on the event via Twitter and Facebook.

It’s certainly going to be a fun day – I suspect we’ll see lots of items from this collection around the office today:

And with that, we’re done with our Launch Series!  Again, we certainly hope you’ve enjoyed it.  We’d love to get your feedback:

• What did you think about our Windows 7 / Windows Server 2008 R2 Launch Series?
• What do you think about the AskPerf blog in general?
• Are there any topics you would be interested in seeing on AskPerf?

You can leave your feedback as a comment, or send us feedback via the Contacting AskPerf … link at the top of the page.  We’re going to take a short hiatus and we’ll be back to our regular posting schedule in a couple of weeks.  Until then …

- CC Hameed

Hi all, and welcome to Day 21 in our Windows 7 / Windows Server 2008 R2 Launch Series.  Tomorrow is the big day!  To wrap up our Launch Series, I want to talk today about a really cool tool included in Windows 7 and Windows Server 2008 R2 called Problem Steps Recorder.  I am sure we have all had situations where we needed to be able to reproduce a complex issue and just can’t seem to get it.  Often we work with end users, who may be across the country (or planet) from us, and need to be able to understand what they are doing that results in something that we need to fix.  Working through steps over the phone can be problematic at best, and connecting remotely to see what is happening on the other end is often not feasible.  Enter Problem Steps Recorder.

Problem Steps Recorder is a tool that collects and records basically everything you do within a certain scenario and packages it up for easy transport.  Problem Steps Recorder can be invoked by clicking the handy Start button   and typing in “Problem Steps Recorder” or PSR. Just click and it will then launch the application, which should look like this:

Then, you just click the Start Record button and reproduce the problem.  When you are done, click the Stop Record button and it will automatically collect the data and save it as a .ZIP file for easy upload.  Inside the ZIP file will be a file with a name similar to Problem_20090924_1612.mht.  This is a web page archive file and can be opened in Internet Explorer.  I used an application called BadApp32.exe which is just a small app that crashes when you run it.  Once I ran Problem Steps Recorder and ran the app to cause the crash, I stopped recording and then viewed the MHT file. Here is what the output web page looks like:

Recorded Problem Steps

This file contains all the steps and information that was recorded to help you describe the problem to others.

Before sharing this file, you should verify the following:

• The steps below accurately describe the problem.
• There is no information below or on any screenshots that you do not want others to see.

Passwords or any other text you typed were not recorded, except for function and shortcut keys that you used.

You can do the following:

• Review the recorded problem steps
• Review the recorded problem steps as a slide show
• Review the additional details

Problem Steps

Problem Step 1: (9/24/2009 4:28:55 PM) User Comment: "I double-clicked this icon."

Problem Step 2: (9/24/2009 4:28:57 PM) User left double click on "Badapp32.exe (list item)"

Problem Step 3: (9/24/2009 4:29:26 PM) User Comment: "Then, I click the little picture of the bomb."

Problem Step 4: (9/24/2009 4:29:28 PM) User left click in "Bad App"

Problem Step 5: (9/24/2009 4:29:53 PM) User Comment: "This causes the application to crash."

Problem Step 6: (9/24/2009 4:29:55 PM) User left click on "Close program (push button)" in "Badapp32.exe"

Additional Details

The following section contains the additional details that were recorded that can help find a solution for your problem.

These details help accurately identify the programs and UI you used while recording the problem steps.

This section may contain text that is internal to programs that only very advanced users or programmers may understand.

Please review these details to ensure that they do not contain any information that you would not like others to see.

Recording Session: 9/24/2009 4:28:29 PM - 4:29:56 PM

Problem Steps: 6, Missed Steps: 0, Other Errors: 0

Operating System: 7600.16385.x86fre.win7_rtm.090713-1255 6.1.0.0.2.1

Problem Step 1: User Comment: "I double-clicked this icon."

Program:

UI Elements:

Problem Step 2: User left double click on "Badapp32.exe (list item)"

Program: Windows Explorer, 6.1.7600.16385 (win7_rtm.090713-1255), Microsoft Corporation, EXPLORER.EXE, EXPLORER.EXE

UI Elements: Badapp32.exe, FolderView, SysListView32, SHELLDLL_DefView, WorkerW

Problem Step 3: User Comment: "Then, I click the little picture of the bomb."

Program:

UI Elements:

Problem Step 4: User left click in "Bad App"

Program: BADAPP32.EXE, BADAPP32.EXE

UI Elements: Bad App, BadApp

Problem Step 5: User Comment: "This causes the application to crash."

Program:

UI Elements:

Problem Step 6: User left click on "Close program (push button)" in "Badapp32.exe"

Program: Windows Problem Reporting, 6.1.7600.16385 (win7_rtm.090713-1255), Microsoft Corporation, WERFAULT.EXE -U -P 3520 -S 224, WERFAULT.EXE

UI Elements: Close program, &Close program, Button, CtrlNotifySink, DirectUIHWND, Badapp32.exe, #32770

The output describes what the user did as well as screen shots of what was going on at the time.  In addition, the screenshots included are clickable to view full size. You may also notice that some of the pictures include an entry called User Comment above them.  PSR has an additional button titled Add Comment.  When you click this button, it allows you to highlight an area of the screen and type in a comment.  This allows you to specify additional comments to the repro steps to make it easier to follow during a complex recording.  The section at the bottom of the page above describes in text exactly what you did at each step, what program was involved and what UI elements were invoked.

The repro I did was very small and pretty much included nothing more than running an app and then clicking inside the app to cause it to crash.  However, you can use Problem Steps Recorder to record much longer or more complex scenarios, and it will track everything you did between the time you click the Start Record and Stop Record buttons.  This makes Problem Steps Recorder a powerful tool in your bag of tricks.  As soon as you can get your hands on Windows 7 or Windows Server 2008 R2, I recommend playing around with this tool and as soon as you do I am sure you will be able to find plenty of scenarios to use it.

So, that is all for this post, thanks again for tuning in.  Remember – LAUNCH DAY is tomorrow!

- Tim Newton

Share this post :

Hello AskPerf Readers!  Day Twenty … only a couple more days to go!  The excitement is building.  Today we are going to take a very quick look at the new and powerful addition of Federated Search in Windows 7.  Federated Search expands the ability of search beyond the users PC and is all about simple lightweight access with a common, familiar user interface.  It can help you find and act on documents anywhere in the enterprise, not just those indexed on your local computer.  Any server compatible with the OpenSearch standard such as Microsoft Office SharePoint 2007 servers can now be searched directly from Windows Explorer.  All you need to do is install a “search connector” pointing to the server location before you can search it.  Best of all, search results in Explorer get all the normal functionality of files in Explorer like drag & drop, preview, open, print, and e-mail. So, let’s get started:

Here is an example showing the installation of the search connector for the MSDN Channel9 website.  The search connector is available on the Channel 9 Search page:

Clicking on the link brings up the dialog to add a Search Connector:

Once installed, I can search for “Windows 7” in the search field from the Explorer window and get direct results from the Channel 9 site.  Notice that Channel9 has been added to favorites, preview icons, and highlighted results.

So that’s how you add a connector – but how does it work?

Windows 7 supports the connection of external sources to the Windows Client through the OpenSearch 1.1 protocol.  The OpenSearch v1.1 standard defines simple file formats that can be used to describe how a client should query the Web service for the data store and how the service should return results to be rendered by the client.  Windows Federated Search connects to Web services that receives OpenSearch queries, and returns results in either the RSS or Atom XML format.

The connection to the web services is provided by Search connectors.  These are Search Connector Description files with the .osdx file extension.  A sample of a .osdx file can be found in the Windows 7 Federated Search Provider Implementer’s Guide and on other MSDN pages (see the links below).

To register a new remote data source with Windows Federated Search, the end-user can open an .osdx file by clicking on a link to one placed on a web site or by opening one provided by someone else on a share or via an email attachment for example. This makes deployment of this functionality very easy and straightforward.

That’s it for the day.  Tomorrow, Tim Newton will be wrapping up our Launch Series with an overview of Problem Steps Recorder.  See you tomorrow!

Additional Resources:

• Windows 7 Federated Search Provider Implementer’s Guide
• Creating an OpenSearch Description File in Windows Federated Search
• Microsoft Tech-Ed Online: Windows 7 Federated Search

- Jerry Ciferri

Share this post :

Happy Monday everyone.  It’s Day Nineteen of our Launch Series, which means that there are only three more days until Windows 7 appears on store shelves!  Today, we’re going to provide a really quick overview of AppLocker, which is a new feature in Windows 7 and Windows Server 2008 R2.  AppLocker replaces the Software Restriction Policies (SRP’s) that many of you are probably familiar with.  With AppLocker, an administrator has the ability to control how users run all types of applications – scripts, excecutables, Windows Installer files (.msi and .msp files) and Dynamic Link Libraries (DLL’s).  Seasoned admins have probably made use of SRP’s in the past, but some of you may be wondering why this is even an issue.

Most of us on the Performance team were IT Administrators at one time or another prior to joining Microsoft.  Believe me when I tell you that we all have our fair share of horror stories.  We’ve all been in environments where end-users have brought in software from home or downloaded some sort of shareware or freeware and installed it on their machine.  In most of these cases, there was no real business need for these apps – let’s face it, is having a “cool” screensaver really a justifiable business application?  Probably not in the vast majority of cases.  Of course, almost inevitably, the software would cause other issues – leading to more helpdesk calls, some fairly angry end-users and of course, some really angry IT folks.  Enter SRP’s, where administrators could create rules and policies to block the installation of some of the more … popular … pieces of unauthorized software.  We’re really not going to get into the workings of Software Restriction Policies – if you need more information, refer to this TechNet Article.

Getting back to AppLocker, there are several enhancements:

• Ability to define rules based on attributes derived from a file’s digital signature, including the publisher, product name, file name and file version.  SRP supports certificate rules, but they are less granular and are a bit more difficult to define
• More intuitive enforcement model – only a file specified in an AppLocker rule will be allowed to run
• Audit-Only enforcement mode that allows administrators to determine which files would be prevented from running if the policy were in effect
• New interface accessed through an MMC snap-in extension to the Local Policy and Group Policy snap-ins.  The Software Restriction Policies snap-in is still available in Windows 7 / Windows Server 2008 R2 for compatibility reasons.

AppLocker requires the Application Identity Service.  This service performs all of the rule conversions for the AppLocker policy.  In order for an AppLocker policy to be evaluated on the system, the services has to be started.  The Application Identity is set to Manual by default.

The effects of AppLocker rules may be viewed in the AppLocker Operational event channel in Event Viewer.  Each event in the AppLocker operational log contains the following information:

• The file affected and the path of the file
• Whether the file was allowed or blocked
• The rule type (path, file, hash or publisher)
• Rule name
• SID for the user targeted in the rule

Something to note – AppLocker rule and Software Restriction Policy rules are completely separate.  You cannot use AppLocker rules to manage pre-Windows 7 systems.  If you define any AppLocker rules in a GPO, only those rules will be applied.  In other words, you should define your AppLocker rules in a separate GPO from your SRP rules to ensure interoperability.

And that’s all for AppLocker.  The resources below have more information.  Tomorrow, Jerry Ciferri will provide a quick overview of Windows Federated Search. 

Additional Resources:

• Windows 7 Walkthrough:AppLocker
• AppLocker Technical Documentation

- Dane Smart

Share this post :

Happy Sunday everyone!  It’s Day Eighteen of our Windows 7 / Windows Server 2008 R2 Launch Series – only four more days to go till the big day!  Today we’re wrapping up our look at some of the new Remote Desktop Services features with a quick overview of Remote Desktop IP Virtualization (RD IP Virtualization).  RD IP Virtualization allows IP addresses to be assigned to remote desktop connections on a per-session or per-program basis.    Prior to Windows Server 2008 R2, every session on a remote desktop server had the same IP address.  I’m sure some of you are wondering, “Well, OK – big deal.  Why does that matter?”  Think about applications that require a unique IP address for each instance of the application.  Clearly having a single IP for all the sessions, can cause a number of application compatibility problems – consider the scenario below where the backend database server refuses the second and third client connections based on their use of the same IP address as the first connection.

OK, let’s take a quick look at the architecture of the RD IP Virtualization feature.  User mode applications using WinSock will be able to get Virtual IP’s – the application itself does not need to be aware of RD IP Virtualization or need to be changed in any way.  However, there are some caveats – services in Session 0 will not be virtualized, nor will applications and services running inside the a remote administrator session.  In addition, applications that use named pipes or any other mechanism besides sockets will not be virtualized.  The RD IP Virtualization Service depends on a valid DHCP Server being active.  A pool of static addresses can also be configured.  The actual process for assigning the IP Addresses is as follows (the diagram below shows the sequence):

1. The RD IP Virtualization Client Layered Service Provider (LSP) intercepts WinSock bind() and connect() calls.  It calls the RD IP Virtualization Service and requests IP addresses
2. The RD IP Virtualization Service calls into the DHCP client.  This call returns either a Machine IP (MIP), Virtual IP (VIP) or an access denied error
3. The RD IP Virtualization Client writes the VIP address to the WTSInfoClass which is returned by WTSQuerySessionInformation().
• In order to determine what users have what IP’s at what time, WTSEnumerateSessions is called to get a list of sessions
• For sessions in the list, WTSQuerySessionInformation is called to get the IP Address.  The session is not virtualized if the call fails and GetLastError() returns ERROR_NOT_SUPPORTED or RPC_S_SERVER_UNAVAILABLE
• WTSQuerySessionInformation is also called to retrieve the user name for the session

A couple of things to note about permissions – only administrators will be able to query and see virtual IP addresses from all sessions.  Users will only be able to see the IP address of their session – they cannot see the VIP’s of other sessions – also, the Remote Desktop User group cannot query VIP’s for all sessions.  Now let’s look at how applications get their IP Addresses and what RD IP Virtualization does in each case.

WinSock provides a pluggable Service Provider Infrastructure (SPI) that facilitates the interception of the WinSock API calls.  Applications don’t know about the SPI – they make their normal WinSock API calls to get network addresses.  Transport Service Providers (TSP) are services that set up the connection or transfer data.  There are two different types of TSP – Layered Service Providers, that we mentioned above, that intercept the WinSock API calls, and Base Service Providers (BSP) that implement lower-level protocols such as TCP/IP.  Namespace Providers (NSP) are services that associate network addresses with human-friendly names.  Since the applications using Namespace Service Providers are also WinSock applications, they are intercepted and assigned VIP’s as well.  The diagram below gives you an idea of how this all interacts:

Now that we’ve looked at some of the underlying architecture, let’s take a look at the functional pieces.  RD IP Virtualization is installed as part of the Remote Desktop Server Session Host role service, but by default it is set as “Not Enabled”.

To enable IP Virtualization, check the box as shown below, and click on Apply.  You can then select if you are going to use Per Session or Per Program mode as well as select which NIC to use to host the Virtualized IP Address.

Before we wrap up, let’s take a look at how to configure a Static IP Pool for RD IP Virtualization.  Normally you would allow your DHCP server to handle the addresses, but if you want to set up a specific set of IP addresses (possibly due to firewall rules etc), here’s how you go about doing that.  Remember that these addresses need to be excluded from the list of addresses that your DHCP server can hand out so that you can avoid IP Address conflicts!  The basic steps are to turn on Static IP via the registry (there is no UI method to do this), then choose your IP Virtualization mode (per-app or per-session) and add your IP address information.  Let’s walk through the process.

The first step is to pop open REGEDIT.EXE and navigate to the HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\TSAppSrv\VirtualIP key.  Once you are at that key, you’ll need to add the following values:

• EnableVirtualIP – set this to a DWORD value of 1
• VirtualMode – set this to a DWORD value of either 0 (per-session mode) or 1 (per-application mode)
• AdapterAddress – set this to a String (REG_SZ) value with  the MAC address of Physical Network card that you are using for the IP Address Virtualization
• IPPool – set this to a String (REG_SZ) value of %SystemRoot%\system32\TSVIPool.dll

Once you have these values configured, you’ll need to go in and add the IP Address information.  Navigate to HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\TSAppSrv\VirtualIP\IPPool and create the following values as String (REG_SZ) values:

• Start – the starting IP address for your VIP addresses
• End – the ending IP address for your VIP addresses
• SubnetMask – the subnet mask for your VIP address range

If you chose to set up your server in per-application mode, you will need to add the applications you want to virtualize.  You can do this via the UI – ensure that the “Per program” radio button is selected and use the “Add Program” button to add the applications:

OK – that’s it for today’s post.  That also wraps up our segment on some of the new Remote Desktop Services features.  Tomorrow, Dane Smart will be back with a quick look at AppLocker.  Until next time …

- CC Hameed

Share this post :

Hey folks – in the midst of our Windows 7 / Windows Server 2008 R2 Launch Series, we have some information regarding Argentina and the DST change.  Argentina has determined that they will not be observing the DST change on October 18th.  The time change (moving the clocks forward one hour) was originally scheduled to occur at midnight between Saturday, October 17th and Sunday, October 18th.

In order to prevent the time changing, uncheck the “Automatically adjust clock for Daylight Saving Time” box:

Below is a scripted method to uncheck this box:

Create a script to uncheck the “Automatically adjust clock for Daylight Saving Time” time zone setting on Windows Servers / Desktop Operating Systems

1. Click Start, click Run, type notepad, and then click OK.
2. Copy the following registry information, and then paste it into the Notepad document:

   Windows Registry Editor Version 5.00
   
   [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
   
   "DisableAutoDaylightTimeSet"=dword:00000001
   

   
   
3. On the File menu, click Save As.
4. Select a destination, and then type DSToff.reg in the File name box. 
5. In the Save as type box, click All Files, and then click Save.
6. Import this registry key on target machines by double clicking in the DSToff.reg and clicking ‘Yes’ when prompted. Execute this registry file in all machines (clients and servers) where you want to “un-select” the “Automatically adjust clock for Daylight Saving Time” setting.
7. In order to deploy these time zone changes in a corporate environment, you can use a startup script as described below.

Deploy DST Modifications using Group Policy

1. Click Start, click Run, type notepad, and then press ENTER. 
2. Copy the following code, and then paste it into the Notepad document. Note:  You must replace the \\contoso.com notation below with the actual DNS domain name for your Active Directory domain.

@echo off
regedit /s \\contoso.com\NETLOGON\DSToff.reg
ver |find /i "6.0">nul
IF %errorlevel% EQU 0 GOTO end
:end



3. On the File menu, click Save As.
4. Enter DST2009Update.cmd in the File name box. 
5. In the Save as type box, click All Files, and then click Save. 
6. Copy the following files to the Netlogon share folder of the domain controller that holds the PDC emulator role in the domain:
   DSTOff.reg 
   DST2009Update.cmd
7. Wait until Active Directory replication occurs. Also, wait until the files and folders in the system volume (SYSVOL) shared folder replicate to domain controllers in the domain. 
8. Click Start, click Run, type control admintools, and then click OK. 
9. Double-click Active Directory Users and Computers. 
10. Select an Organizational Unit (OU) which contains the computers that you want to apply this script to. In this example, we will use an OU that is named DST-COMPUTERS. This example also assumes that this OU contains computer accounts.
11. Right-click the DST-COMPUTERS OU and then click Properties. 
12. Click the Group Policy tab, click New, type DST Registry Update, and then press ENTER. 
13. Click Edit. The Group Policy Object Editor tool starts.
14. Expand Computer Configuration, expand Windows Settings, and then click Scripts (Startup/Shutdown). 
15. Double-click Startup, and then click Add. 
16. In the Script Name box, type the universal naming convention (UNC) path of the DST2009Update.cmd file that is located in the Netlogon share. For example, type \\contoso.com\NETLOGON\DST2009Update.cmd. 
17. Click OK two times. 

Note: Client computers that are within the DST-COMPUTERS organizational unit will run the startup script the next time the machine starts up, meaning all machines needs to be restarted to be able to recognize the new DST configuration via Startup script.

The instructions above can be applied on Windows 2000, Windows XP and Windows Server 2003 systems.  The instructions above should not be used on Windows Vista or Windows Server 2008 Systems.  On these systems, please uncheck the “Automatically adjust clock for Daylight Saving Time” manually.

- Jeff Worline

Good Morning AskPerf Nation!  Our Launch Series is at Day Seventeen.  There are only five more days to go!  Today we’re continuing on with Remote Desktop Services, with a look at Remote Desktop Services Virtualization (or RDS-V, for short).  You may also hear RDS-V referred to as Virtual Desktop Infrastructure (VDI).  RDS-V provides remote desktop access to managed desktop environments hosted in Hyper-V on Windows Server 2008 R2.  OK, there are way too many technical buzzwords in that last sentence, aren’t there?  Simply put, in the same way that RemoteApp makes applications available to users through individual Remote Desktop Services sessions, RDS-V provides access to specific virtual machines (desktops) through a similar mechanism.  So, what does it really do?

RDS-V uses the Remote Desktop Connection Broker to determine where the user is redirected.  If a user is assigned and requests a personal virtual desktop, RD Connection Broker redirects the user to this virtual machine.  If the VM is not turned on, RD Virtualization turns on the VM and then connects the user.  If the user is connecting to a shared virtual pool, then the RD Connection Broker checks to see if the user already has a connected session in the pool.  If the user has a disconnected session then they are reconnected to that VM.  If the user does not have a disconnected session, a VM in the pool is dynamically assigned to the user – if one is available.  A quick note here, the Hyper-V server role has to be installed on the same system that has the RD Virtualization role service installed.  Let’s take a quick look at the fairly simple high-level RDS-V topology:

The different components of RDS-V are as follows:

• Connection Broker – given an authenticated user and their associated request for an application or desktop, the Broker determines which RDS Server or VM image can best satisfy the request
• Redirector – RD Session Host Server whose purpose is to query the Broker on the RDS Client’s behalf.  After querying the Connection Broker, the Redirector sends an RDP redirection packet back to the RDS Client
• RDS Assignment Database – representation of the AD Schema extensions that provide end-user mappings to a particular VM Host image
• Web Portal – web page that shows the user all the applications / desktops they can access
• VM Host – Machine on which the VM images are hosted.  The VM Host Agent service runs on this machine.  The service is controlled by the Connection Broker and can perform certain actions such as spinning up a VM image

The diagram above breaks out the different components and their functions.  Let’s take a closer look at the Connection Broker’s functions:

There are some basic steps that the Connection Broker performs.  If the endpoint for the request is a farm, then the Connection Broker has to check the cache of user sessions to see if there is an existing disconnected session within that particular farm.  The key here is that the disconnected sessions are farm-specific. If the user does not have a session, the Connection Broker chooses the best machine or VM image within the farm.  There is also some machine logic that takes place.  Connection Broker calls into the type-specific VM Plug-in to carry out what is called Placement.  This action involves the plug-in move the necessary VM image to the best VM Host and then return the name of that host.  For VM calls specifically (as opposed to RemoteApp requests), the Connection Broker calls into the VM Host Agent to spin up the VM image.  This is called Orchestration.  The return value of this step is a list of IP addresses for the final machine / image to which the RDS Client should be redirected.  These steps are executed each time a user connects.  In addition, the Connection Broker also has a “Pool Creator”.  This component coordinates the creation of VM farms by directing VM Host Agents to create farm-joined VM instances out of template VM images.

The flowchart below outlines the logic that is followed by the Connection Broker when a VM connection request is made:

OK folks – with that, we’ve reached the end of today’s post.  A couple of quick things to keep in mind:

1. Don’t install the Remote Desktop Virtualization (RD Virtualization) role service on the same system on which you have installed the Remote Desktop Connection Broker (RD Connection Broker) role service
2. The RD Virtualization server is only needed if you plan to deploy and configure virtual machines as virtual desktop pools or personal virtual desktops
3. Before configuring the Remote Desktop Session Host (RD Session Host) server to provide redirection to virtual desktops, ensure that the computer account for the RD Session Host server is a member of the Session Broker Computers group on the Remote Desktop Connection Broker (RD Connection Broker) server

Now, I know that we didn’t do a full walkthrough on the “How To’s” for this entire process.  If that’s something that you would like us to go over – let us know.  And now, we really are at the end of our post.  I’ll be back tomorrow with a look at Remote Desktop Services IP Virtualization.  Until tomorrow …

- CC Hameed

Share this post :

Welcome back – Happy Friday!  Day Sixteen of our Windows 7 / Windows Server 2008 R2 Launch Series is upon us. There are only six more days to go and excitement is growing!  Following on from yesterday’s post, today we’re going to take a look at the specifics of Connection Broker for Windows Server 2008 R2 in this post and look at exactly how you configure and use the new features of this enhanced technology for Remote Desktop Services.

As with other server roles and role services, installing Connection Broker is very straightforward. The easiest way to do this is by using Server Manager and selecting the Connection Broker role service under the Remote Desktop Services role service:

You should not be asked any other questions at this point and the Connection Broker service should install with no further prompts.  You will likely not even to reboot the server after the installation.  One quick note here - you will want to choose a server that is not also a RD Session Host or has other roles like RDS Gateway on which to install the RD Connection Broker if possible.  A Domain Controller makes a good candidate for a RD Connection Broker as it will usually not also have one of the other RDS roles except Remote Desktop Licensing.  Prior to Windows Server 2008 R2, the Session Broker service itself didn’t require any configuration.  There really wasn't anything you could configure anyway, since all of the settings were displayed and controlled on the Terminal Servers themselves.  You should notice right away that Windows Server 2008 R2 and Connection Broker now has a management interface:

The Remote Desktop Connection manager is used to configure the new Connection Broker features, and you will soon see that Connection Broker is now complex enough that it was obvious a management user interface was needed.  I am going to use a simple Remote Desktop Server farm with 2 Remote Desktop servers hosting RemoteApps to show how to configure Connection Broker to manage a simple farm.  Some of this was covered yesterday in Dane’s post on RemoteApp and Desktop Connection.  Previously in Windows Server 2008, if you wanted to deploy RemoteApps in a farm you had to build identical servers with the same RemoteApps on each server and then deploy the farm to users.  With Connection Broker in Windows Server 2008 R2 you now have the choice to combine RemoteApps from Remote Desktop servers that have different RemoteApps installed and present them to users on the same web page. To do this, we start by adding RemoteApp sources in Connection Manager. Click on Add RemoteApp Source:

Pay close attention to the warning icon.  The icon is there to remind you that you must add the computer account for the Connection Broker sever to the TS Web Access Computers group on the RD Session Host server.  This is a common misconfiguration so to keep this straight think of it this way: You need to explicitly grant permission to any server that will load RemoteApps from your RD Session Host server.  Remember that you get RemoteApps when you install RD Session Host on a server, and once you have installed your RemoteApp applications and configured them as RemoteApps you must allow your Connection Broker to query your RD Session Host and retrieve a list of RemoteApps.  The same thing needed to be done with TS Web Access in Windows Server 2008 and it still applies in Windows Server 2008 R2.

To view your RemoteApp sources and make sure they were successfully added, go to RemoteApp Sources under Remote Desktop Connection Manager in the left pane of Server Manager:

I have two RemoteApp servers and they both have different RemoteApps installed, so I added them both as RemoteApp sources to Connection Broker.  Now when a user visits the RemoteApp and Desktop Connection page they will see all of the RemoteApps from both servers configured as RemoteApp sources in Connection Broker, provided that I configure the page to load RemoteApps from the Connection Broker:

To complete the configuration though make sure you give the RD Web Access server the explicit permission to query the Connection Broker and retrieve a list of RemoteApps.  This is done automatically when you click Click Add under the RD Web Access servers configuration in the Remote Desktop Connection Manager:

In this example, the Connection Broker and the RD Web Access server are the same server as it has both role services installed, but this should give you the general idea.  Basically, the RemoteApps flow like this: RD Session Host Server <--> Connection Broker <--> Web Access  <—> Client

If you select one or more RemoteApp sources in the RD Web Access configuration above then you are not using Connection Broker to manage your RemoteApps and instead you would enter either a DNS farm name that resolves to one server in a farm with multiple servers that all have the same RemoteApp installed, or you must enter one or more RemoteApp sources separated by a semicolon.  This is essentially the same as how things worked in Windows Server 2008 with one exception: You could only add one RemoteApp server or a RemoteApp farm to TS Web Access.

I don’t want to get too deep into the way Connection Broker helps you deploy virtual desktops as there is going to be a separate blog post about that topic, but I do want to look at the UI of Connection Manager and how you configure the Connection Broker.

The first thing that must be done is to add an RDV server. This is done by clicking on Add next RD Virtualization Host servers:

The RDV Host is the server where RD Virtualization Host was installed, or your Hyper-V server. If Hyper-V is not installed when you install the RDV then it will be added as a required role service.

Once you have added your RDV Host server you would then add a RD Session Host redirector (which is basically a RDS Host in drain mode:

Finally, you would then assign Personal virtual desktops if you are going to use them by clicking on Assign next to Assign Personal virtual desktops to run the wizard:

That’s it for today!  CC will be back tomorrow with a look at Remote Desktop Virtualization (RDS-V).  Enjoy the rest of your Friday!

-Don Geddes

Share this post :

Good Morning AskPerf!  Welcome to Day Fifteen of our Launch Series.  There is only one more week to go!  If you remember Windows Server 2003 R2 then you probably also remember that Terminal Services (as it was called then) didn’t change much from Windows Server 2003.  The same cannot be said for Remote Desktop Services in Windows Server 2008 R2 when compared to Windows Server 2008.  Today’s post is a brief one where we’ll be taking a look at an overview of Remote Desktop Connection Broker - not only at what is new, but how it is different from its predecessors.  In part 2, we will dive in to the specifics of how to configure and put Connection Broker to work for you in your business.

First, let’s look at a little history of Windows Terminal Services.  Since Windows Server 2003, we have had the ability within Terminal Services to be deployed as a farm where multiple servers were pooled together as a single resource.  This provided the ability to scale out and increase the number of users that could access applications over Terminal Services by distributing them amongst several servers instead connecting hundreds of users to a single server.  If you added in Microsoft Network Load balancing then you could also balance the load across servers in the farm.  This deployment presented some problems though, for example when user sessions were disconnected.  How did we make sure the user is returned to their previous session when they do not know which server they were connected to in the first place?  The solution was Session Directory, and in Windows Server 2003 this was implemented in the Terminal Server Session Directory service.  It was called Session Directory because that is basically what it was, a directory (or database) of sessions for each user in the farm.  The only job Session Directory had in Windows Server 2003 was to redirect a user to a disconnected session.  Load balancing was accomplished with Network Load Balancing or a hardware device like BIG-IP. 

In Windows Server 2008, Session Directory was extended to include load balancing support that was previously only available with hardware devices from companies like Cisco and f5, or software like Microsoft Windows Network Load Balancing.  The feature was renamed to Session Broker and has two main functions:

1. Redirect users to their disconnected sessions
2. Evenly balance the load among servers in the farm

Session Broker was able to add basic load balancing functionality by leveraging the already existing database of sessions in the farm and using that to make a basic load balancing decision.  The topology for Session Directory / Session Broker on Window Server 2003 and Windows Server 2008 looks like this:

The best things about RD Connection Broker in Windows Server 2008 R2 are not what was changed, but rather what was added. RD Connection Broker still supports the same disconnected session redirection and load balancing features of its predecessors, while adding support for pooling RemoteApps from multiple servers and brokering connections to virtual desktops that can be either personalized for each user or assigned to users from a pool of available virtualized desktops.  This is main reason for the name change, as this service now brokers more than just sessions, it brokers connections to applications and desktops that are deployed via Remote Desktop Services and Hyper-V.

The real power of RD Connection Broker is when it is used with Hyper-V and the Remote Desktop Virtualization Host to deploy entire desktops to users, where that desktop is no longer a session on a Terminal Server but a virtual machine.  Working with the RD Virtualization Host, RD Connection Broker now also manages all of these connections and allows for redirection to a standard Remote Desktop session, a RemoteApp session, a personalized virtual desktop, or a connection to a virtual machine pool.  We’re not going to go into too much detail about Remote Desktop Services Virtualization in this post – you’ll have to wait until the day after tomorrow for that!  However, in a nutshell, RD Virtualization Host uses Remote Desktop Connection Broker to determine where the user is redirected.

That’s it for today – a brief post as I mentioned, but the information here relates to the next couple of posts.  I’ll be back tomorrow with Part Two of this post.  Take care!

- Don Geddes

Share this post :