So, this is something I wanted to blog about a few months ago but it got pushed to the bottom of the list of things to do (As usual!). 

Anyway… during the early adopter testing of the Office 365 service we had a number of customers who had deployed what was termed “Exchange Rich Coexistence” or “Hybrid” as it is termed now.  At the time (12 months ago now!) the documentation to get this up and running was fairly patchy and it took quite a bit of trial and error to get things working as people wanted.  However, most customers managed to get things working after 4 weeks or so and were able to begin testing…

Then came the problem… we had talked most of our customers through deploying DIRSYNC at around the same time (within a few days of each other), imagine our confusion when they all stopped working at pretty much the same time!  Lots of red errors in the event logs… this was one of the errors from my test lab…

OK, so its pretty clear that we have an authentication problem, but which credentials, our terra-firma or cloud?  and how do I fix it?

Well, it turns out that the the problem is pretty predictable… its caused by the 90 day password expiry policy applied to all Office 365 managed accounts, this will happen repeatedly every 90 days.  In the case of our early adopters they all hit this within 2 days of each other because everyone was so keen to get up and running that they pretty much all installed DIRSYNC as soon as we made the code available!

Luckily we have a couple of ways around this…

1. Establish an operations process every 90 days to change the password and reconfigure DIRSYNC
2. Create a service account for DIRSYNC and disable password expiry

For this blog I will concentrate on option 2 and how to reconfigure DIRSYNC after you have created a new account.

Note: If you can create this managed account before setting up DIRSYNC for the first time, then you wont have to visit it again!

Creating an Office 365 service account for DIRSYNC…

The first thing we need to do is to create an Office 365 managed account to use for DIRSYNC.  I find it easiest to do this in the GUI.

1. Login to https://portal.microsoftonline.com as a tenant Administrator
2. Under the Management menu, click on Users
3. Click on New, then select User from the drop down
4. Enter the appropriate details for the new user account and click next
5. Assign the new account “Global Administrator” rights
6. Complete the user creation process (You do not need to assign this user an Office 365 License!)
7. Make a note of the temporary account password
8. Start IE in “InPrivate” mode and browse to https://portal.microsoftonline.com
9. Login with your new DISRYNC service account
10. On first login Office 365 will prompt you to change the password
11. Verify that you can logon to the Office 365 portal with your new account

Re-configuring DIRSYNC to use the new Office 365 service account…

Before we can complete this section, we are going to need a few bits of information…

• Local Active Directory Enterprise Administrator Account details and password
• DIRSYNC service account details and password in Office 365

Process…

1. Logon to your DIRSYNC server
2. Open Start –> All Programs > Microsoft Online Services –> Directory Synchronization : Directory Sync Configuration
3. Click Next at the welcome screen
4. Enter your new DIRSYNC service account details into the Microsoft Online Services Administrator Credentials box
5. Click Next (DIRSYNC will validate your credentials)
6. Enter your existing Enterprise Administrator Credentials into the Active Directory Enterprise Administrator Credentials box
7. Click Next (DIRSYNC will validate your credentials)
8. Enable the "Rich Coexistence” checkbox if you are deploying in “Hybrid” and want AD write-back
9. Click Next
10. DRSYNC Will re-configure itself to use the new account
11. Ensure that the Synchronize directories now checkbox is checked and click “Finish”
12. Start Event Viewer and open the Application Log
13. Look for Directory Synchronisation Events 1 – 4 (4 means its finished “Export has completed”)

OK, so now we have a new account dedicated for DIRSYNC, but its password is still going to expire in 90 days…

Disabling password expiry on your Office 365 DIRSYNC service account…

Now, before we go through these steps it is important to realise that disabling your DIRSYNC service account password expiry has some obvious security risks involved.  This is a powerful account with full rights to your tenant, if it gets compromised then so does your entire tenant!  Make sure that you fully understand these risks before continuing and discuss appropriately with your security team.

OK, so assuming you have decided to go ahead this is what we will need…

Install the Microsoft Online Sign-In Assistant

• Microsoft Online Services Sign-In Assistant 32-bit
• Microsoft Online Services Sign-In Assistant 64-bit

Install the Microsoft Online Services Module for PowerShell

• Microsoft Online Services Module for Windows PowerShell 32-bit
• Microsoft Online Services Module for Windows PowerShell 64-bit

Launch a PowerShell Window and run the following commands…

   1: Import-Module msonline

   2: $cred = Get-Credential

   3: Connect-MsolService -cred $cred

   4: Get-Command –Module msonline

Once connected we have access to some new MSOL Remote PowerShell cmdlets.  We are going to make use of the get-msoluser and set-msoluser cmdlets.

Firstly, lets take a look at our DIRSYNC service account as it was originally created

• get-msoluser –userprincipalname dirsync@neiljohn.onmicrosoft.com | fl

   4: ExtensionData               : System.Runtime.Serialization.ExtensionDataObject

   5: AlternateEmailAddresses     : {dirsync@neiljohn.onmicrosoft.com}

   6: BlockCredential             : False

   7: City                        :

   8: Country                     :

   9: Department                  :

  10: DisplayName                 : DIRSYNC Service Account

  11: Errors                      :

  12: Fax                         :

  13: FirstName                   : DIRSYNC

  14: ImmutableId                 :

  15: IsBlackberryUser            : False

  16: IsLicensed                  : False

  17: LastDirSyncTime             :

  18: LastName                    : Service Account

  19: LicenseReconciliationNeeded : False

  20: Licenses                    : {}

  21: LiveId                      : 10033FFF80B3EF03

  22: MobilePhone                 :

  23: ObjectId                    : d756d167-fcf3-4505-99e2-fd1100952182

  24: Office                      :

  25: OverallProvisioningStatus   : None

  26: PasswordNeverExpires        : False

  27: PhoneNumber                 :

  28: PostalCode                  :

  29: PreferredLanguage           :

  30: State                       :

  31: StreetAddress               :

  32: StrongPasswordRequired      : True

  33: Title                       :

  34: UsageLocation               : GB

  35: UserPrincipalName           : dirsync@neiljohn.onmicrosoft.com

  36: ValidationStatus            : Healthy

As you can see from the output, PasswordNeverExpires is to to False, this means that our service account user will inherit the standard 90 day password expiry policy.  To change this we need to issue the following command…

• Set-MsolUser -UserPrincipalName dirsync@neiljohn.onmicrosoft.com -PasswordNeverExpires $true

If we then repeat the earlier command, we can see that now PasswordNeverExpires is now set to True

   1: ExtensionData               : System.Runtime.Serialization.ExtensionDataObjec

   2: AlternateEmailAddresses     : {dirsync@neiljohn.onmicrosoft.com}

   3: BlockCredential             : False

   4: City                        :

   5: Country                     :

   6: Department                  :

   7: DisplayName                 : DIRSYNC Service Account

   8: Errors                      :

   9: Fax                         :

  10: FirstName                   : DIRSYNC

  11: ImmutableId                 :

  12: IsBlackberryUser            : False

  13: IsLicensed                  : False

  14: LastDirSyncTime             :

  15: LastName                    : Service Account

  16: LicenseReconciliationNeeded : False

  17: Licenses                    : {}

  18: LiveId                      : 10033FFF80B3EF03

  19: MobilePhone                 :

  20: ObjectId                    : d756d167-fcf3-4505-99e2-fd1100952182

  21: Office                      :

  22: OverallProvisioningStatus   : None

  23: PasswordNeverExpires        : True

  24: PhoneNumber                 :

  25: PostalCode                  :

  26: PreferredLanguage           :

  27: State                       :

  28: StreetAddress               :

  29: StrongPasswordRequired      : True

  30: Title                       :

  31: UsageLocation               : GB

  32: UserPrincipalName           : dirsync@neiljohn.onmicrosoft.com

  33: ValidationStatus            : Healthy

OK, so now we are done!  DIRSYNC will no longer require that your account password is changed every 90 days.

Conclusion

This is a more interesting topic than I had originally, thought, the actual process to configure a service account without password expiry is relatively quick and simple, however there are significant security implications from having an Office 365 account that never requires its password to be changed with such high access rights.

For me what this configuration does is to put the control back into the hands of the Administrator – you now have control over when you change your service account password.  My experience with fixed password expiry on service accounts is that eventually the password will expire when the person responsible for that service is on leave or away sick and nobody else knows what to do – this is a recipe for further disaster.

I would recommend combining this solution for disabling password expiry with an operations process to change the password regularly.  This process should be documented clearly and executed regularly to meet your security policies.  This approach gives you the flexibility of being able to choose your own account password change policy, without the risk of the password expiring and stopping your directory sync process from working.

This has been an interesting bit of work for me.  I have been working with a customer who really needed to provide their users with the ability to manage calendars across different Exchange organisations.  When they initially presented this requirement to me, my first thought was that we would be able to provide cross-forest availability sharing but that cross-forest delegation was not going to be possible…

So, as with most projects like this I began by asking my colleagues and quickly discovered that some thought it was possible and some thought it wasn't.  This at least gave me the incentive to dig a little deeper to determine what we could and couldn't achieve.  This digging discovered a few articles about ILM FP1 SP1 and FIM that showed a check box called “support cross-forest delegation (Exchange 2007 or 2010 only)”…

A little more research suggested that given a few pre-requisites it should be possible to achieve cross-forest delegation for Outlook users.  This article will briefly go through the required steps and link to further information to assist with configuration…

Prerequisite requirements

To get cross-forest delegation to work the following prerequisites must be met…

• Forest Trust between Forests
• Cross-Forest Availability Configured
• GALSYNC configured with either ILM FP1 SP1 or FIM 2010 (or manual cross-forest mail contacts created)
• Exchange Server 2007 SP1+
• Outlook 2007 SP1+

Forest Trust

Before we continue we need to establish a forest trust between the forests…

• http://technet.microsoft.com/en-us/library/cc780479(WS.10).aspx 
  

Cross-Forest Availability

The next step is to establish cross-forest availability.  This provides users availability data between exchange organisations.

Note:  The documentation in TechNet regarding cross-forest availability is particularly difficult to follow.  Where the examples contain reference to the “Client Access Servers” group you must either create this group and add in your CAS servers or simply use “Exchange Servers” instead.  Additionally the steps assume that your CAS servers are using public certificates that are trusted – if you are using an internal PKI CA you must ensure that all of your CAS servers trust the root CA.

• http://technet.microsoft.com/en-us/library/bb125182.aspx

Here is my short-cut version of that guidance…

Run In the source forest

• Add-AvailabilityAddressSpace -ForestName "TargetSMTPnamespace.com" -AccessMethod PerUserFB -UseServiceAccount $true

Run In the target forest

• Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "Source Forest\Exchange Servers"

Note: You must perform these steps in both forests for a 2-way configuration

Configuring cross-forest Autodiscover

• $a = Get-Credential <Enter Administrator credentials in the remote forest when prompted>
• Export-AutoDiscoverConfig -DomainController <Local GC> -TargetForestDomainController <Target GC> -TargetForestCredential $a -MultipleExchangeDeployments $true

So, by the time we get here it should be possible to lookup availability data for a user in the other forest.

GALSYNC

This is where the secret sauce happens for cross-forest delegation.  Basically we are going to use FIM in this example to read in mailbox objects from each forest and create contacts in the target forest to build a common GAL for both Exchange Organisations. 

The official guidance for configuring this is available here, however I have included my steps as well below

• http://technet.microsoft.com/en-us/library/aa998597.aspx

The steps I follow are as follows…

Note:  I generally create an OU in each forest called Contacts to receive contacts from FIM.  These steps assume that you have created this OU already.

1. Open Synchronisation Service Manager (FIM)
2. Click on Management Agents
3. On the Actions Menu, click Create
4. Select Active Directory global address list (GAL) from the Management Agent drop down
5. Enter a name for this MA and click Next
6. Enter the forest name and credentials that this MA will retrieve information for and click next
7. In Select directory partitions enable the checkbox for the root of the forest
8. Click on Containers
9. Deselect all OU’s and manually select OU’s that contain mailboxes + ensure that the Contacts OU is checked and click ok
10. Click Next
11. Click Target, Click Container and Check the Contacts OU and click Ok
12. Click Source, Add Containers and check all OU’s that contain mailboxes, then click OK
13. Under Exchange configuration, click Edit, Add in the SMTP namespace you want the contacts to use that are created for this forest, click Add and finally OK
14. Check Route mail through this forest for all contacts created from contacts in this forest
15. Check Support cross-forest delegation (Exchange 2007 or 2010 only)
16. Click Next
17. Click Next until the Configure Extensions page is displayed
18. In the Exchange 2010 RPS URI: Enter http://<CAS Server>/Powershell
19. Click Finish

Repeat these steps for all forests.

Note:  By default ILM and FIM have provisioning disabled, to enable provisioning click on Tools, Options and check the Enable Provisioning Rules Extension checkbox.

Once all MA’s have been created run the following profiles (Right click on the MA, select RUN)

1. Full Import (Staging Only)
2. Full Synchronization
3. Export
4. Delta Import

Finally check the contacts OU in each forest to ensure that FIM has populated it with contacts from the remote organisation.  If there are problems, the first thing to do is check the event logs on the FIM server to begin troubleshooting…

User Experience

By this point you should now have a common global address list amongst your Exchange Organisations and if you look into the Contacts OU it should be populated with contacts from the remote organisations.  If you look in the Exchange Management Console you should see that the contacts have been created as a Recipient Type of Cross-forest mail contact.  This recipient type means that you can use this contact to assign delegate permissions.

In my lab I have two Exchange Organisations in two Forests

• org4.lab (org4user1)
• org5.lab (org5user1)

As a test I am going to delegate calendar editor permissions over org4user1’s to remote user org5user1.  I did this simply by opening the delegates tab on org4user1’s mailbox and tagged in the contact for Org5user1. 

I then logged on to the org5user1’s mailbox and attempted to open org4user1’s calendar.  This worked as expected, so I then attempted to make changes to the shared calendar, again which worked as expected! result

Manually Creating a cross-forest mail contact

So this is an interesting exercise (interesting is relative here obviously, but lets go with it for now!).  My current customer does not have FIM or ILM deployed to synchronise contacts between forests, however they wanted to enable cross forest delegation for a few users.  We have a project planned to deploy FIM to solve this issue strategically but due to the importance of some of the users affected they really pushed me to come up with a temporary solution for cross-forest delegation.

My solution to this was to perform all of the configuration for cross-forest availability and then to manually create the cross-forest mail contacts in the target forest.  The challenge of course was how to create a cross-forest mail contact!

After some investigation the following attributes looked to be of interest…

• mAPIRecipient = TRUE
• msExchMasterAccountSID = objectSID from Mailbox
• msExchOriginatingForest = Target Forest FQDN
• msExchRecipientDisplayType = –1073741818
• msExchRecipientTypeDetails = 32768
• proxyAddresses = X500: + LegacyExchangeDN from Mailbox; existing addresses

Here is an example…

Source Mailbox Attributes for Org4User1@org4.lab

• legacyExchangeDN: /o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
• mail: Org4User1@org4.lab;
• mailNickname: Org4User1;
• objectSid: S-1-5-21-1575148580-663765585-2685387708-1129;

Cross-forest mail contact attributes for Org4User1@org4.lab

• legacyExchangeDN: /o=Org5/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
• mail: Org4User1@org4.lab;
• mailNickname: Org4User1;
• mAPIRecipient: TRUE;
• msExchMasterAccountSid: S-1-5-21-1575148580-663765585-2685387708-1129;
• msExchOriginatingForest: org4.lab;
• msExchRecipientDisplayType: -1073741818;
• msExchRecipientTypeDetails: 32768;
• proxyAddresses (2): X500:/o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1; SMTP:Org4User1@org4.lab;
• targetAddress: SMTP:Org4User1@org4.lab;

Conclusion for Cross Forest Delegation in Exchange Server

I must admit that I did feel like I had missed a day at school when I first started this.  For me this is a huge feature area that is pretty poorly documented and even the fact that you can do cross-forest delegation is relegated to a one liner in TechNet under the cross forest implementation section.

However, the user experience is absolutely great once this is configured and in fact it is difficult to tell which organisation a user is from simply by the features you have enabled, i.e it doesn't really matter to a user where the people are that they are collaborating with, everything just works.

Update:  Quite a few people have asked me about licensing for FIM when used only for GALSYNC.  My understanding here is that the GALSYNC MA is free of charge and so the only thing you need to purchase is the FIM Server License (no CAL’s are required) + Server + SQL licenses.

This functionality was first made available in ILM FP1 SP1 and works with Exchange 2007 SP1 and Exchange 2010.  The clients need to be Outlook 2007 or above.

This is obviously not a post about Exchange Server, but as a blogger I wanted to share this since it's been something that has been irritating me for some time…

Basically I like to write in Word rather than Live Writer. Live Writer is great but I spend a lot of time writing documentation in Microsoft Word 2010 and so that is my preferred writing tool. Most of my blog posts start off life in Word 2010 and then I have to transfer them over to Live Writer to get the content uploaded to my Blog. The problem is that the formatting is often lost during the transfer and I have to spend time trying to make it look how I wanted in the first place… surely there must be a way to get Word 2010 to write to my TechNet blog in the first place? Surely?? J

So… after some searching and some trial and error I have finally managed to come up with a solution to connect Word 2010 with the TechNet Blog platform…

Connecting Word 2010 to TechNet Blog Platform

1. Open Microsoft Word 2010
2. Click File -> New
3. Pick Blog Post from the Available Templates
4. Word should prompt you to Register a Blog Account at this stage
5. Select Register Now
6. In the Choose your blog provider drop down, select Other and click Next
7. Select MetaWebLog in the API type
8. Enter your TechNet blog URL with /metablog.ashx tagged on the end – in my case this ends up being http://blogs.technet.com/b/neiljohn/metablog.ashx
9. Enter your username and password

1. Click OK
2. Your TechNet Blog account is now registered in Word 2010

Hopefully someone else out there will find this useful J

Last week when the internal announcement was made to say that SP2 had been completed and was scheduled for release, I added a few blog articles onto my “to do” list.  Imagine my surprise this morning when I woke up to find that the internets were crammed full of SP2 news and that most of the articles I was planning to write, had already been written! (if only that happened with my design deliverables!)

So, I have decided to write a post today about all of the others posts instead.

Firstly here is a link to download SP2 if that's all you need – I still recommend that you skim through the release notes, even if you are progressing through your own test plan since it may save you some time.

• http://www.microsoft.com/download/en/details.aspx?id=28190
  

Released: Exchange Server 2010 SP2

The Exchange Team Blog (this is owned by the Microsoft Exchange Server Product Group if you were not aware) announced the release of SP2 on Dec 5th at 6.38pm with the following post…

• http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Some interesting things to note…

1. It requires a schema update (just like every other Exchange SP since 2007!)
2. It provides the following new features…
   

• Hybrid Configuration Wizard
• Address Book Policies
• Cross-Site Silent Redirection for Outlook Web App
• Mini Version of Outlook Web App
• Mailbox Replication Service
• Mailbox Auto-Mapping
• Multi-Valued Custom Attributes
• Litigation Hold

Exchange Server 2010 SP2 Release Notes

Before you consider deploying any new service pack for Exchange I strongly urge you to take a look at the release notes…

• http://technet.microsoft.com/en-us/library/hh529928.aspx

For this release the following areas may require attention – all are discussed in the release notes.

• Installation Prerequisites for Client Access Servers has changed
• Possible issue with RBAC on non SP2 servers after upgrading one server to SP2 in the organisation
• Outlook Web App redirection issue after upgrading to SP2
• Mailbox Replication Proxy
• Hybrid Configuration Wizard error with domains starting with a numeric value

It is worth noting here that Exchange Service packs are inclusive of all previous service packs and update rollups.  This means that Exchange Server 2010 SP2 includes the fixes and changes up to and including Update Rollup 6 for Exchange Server 2010 Service Pack 1.

Exchange Server 2010 SP2 Internet Content

This is a subset of the non-TechNet material I recommend reading to get up to speed on Exchange Server 2010 SP2

• Greg Taylor : Featuring GAL Segmentation (This is a TechEd recording on ABP’s)
• Greg Taylor: Exchange Server 2010 SP2 and Support for Hosted Exchange
• Henrik Walther: Changes to the MRSProxy Service Configuration
• Tony Redmond – Installing Exchange 2010 SP2
  

Other Interesting Stuff

I spotted that we released a new version of the Exchange Server User Monitor yesterday also – I don't know if this is required if you deploy SP2 but I thought I would include it here just in case

• Exchange Server User Monitor 14.2.247.5 (EXMON)

Hopefully this provides enough information in one place to save you searching the rest of the internet for your Exchange Server SP2 news

Hello everyone … My name is John Rodriguez, and I'm a Principal PFE based in Minneapolis, MN. I'm also one of Neil's frequent collaborators, particularly on load simulation tools. When he wrote his recent article on performance analysis of Jetstress data, I suggested that he include some of our time-saving tips. He's a busy chap, and asked me to write the article instead. So, to that end, I'm here as a guest contributor to share with you some of the things we as performance specialists do within Perfmon. [Neil: Actually John taught me Exchange perf when I first joined Microsoft in 2007 and again when I went through MCM; it is a great honour to have him write stuff for my blog, so thanks again John J].

If you spend a lot of time in Perfmon, whether for general performance analysis, reviewing Jetstress data, or trying to identify the source of a bottleneck, you tend to look for ways to automate tasks – to simplify things. Thankfully Perfmon provides some extremely useful interfaces which provide us with our time-saving opportunities.

When you first launch Performance Monitor, and switch to the Performance Monitor node, you should see the general screen with a single counter (usually Processor(_Total)\% Processor Time). In the example below, I've deleted the default counter and added four specific ones of great Exchange importance: MSExchangeIS\RPC Averaged Latency, \RPC Operations/sec, \RPC Packets/sec, and \RPC Requests.

How did I add those counters? Believe it or not, I pasted them. Pasted? Into Perfmon? Really? Yes, really. Here's how.

When you first launch Perfmon and want to add counters, you can click the green Plus symbol, or right-click the display and select "Add Counters…" as shown below.

Now, if you look at the context menu, you can see an option to "Save Settings As…" This is one of the most underappreciated items in Perfmon, and enables a lot of incredibly useful behavior. "Save Settings As" predictably enough saves the existing set of counters to an HTML file which you can then open and edit to your heart's content. If you right-click the file and select Open With > Notepad, you should see a bunch of entries beginning with <PARAM NAME="Counter#" and then details on the counters themselves, like so:

[It's important to select Open With > Notepad, rather than double-click on the file. We'll see why in a minute.]

Notice that there's no server name in this data – the value is just the counter name – "\MSExchangeIS\RPC Averaged Latency", "\MSExchangeIS\RPC Packets/sec", and so on. This means that this set is rather portable – to our great advantage. I can use this information to automatically add a whole group of counters to Perfmon at once. But we're not going to load them from the file – we're going to paste them into Perfmon! This may sound odd, but Perfmon actually supports copy-and-paste. If I want to add all of those counters at once, I can simply open that HTML file with Notepad, copy the contents (select all, copy), open Perfmon, click anywhere in the right-hand pane, and then click Ctrl-V, Perfmon will add all of those counters at once. In other words, if you add the counters to one server, and save the settings to HTML, you can quickly add all of those counters for any other server! This is extremely useful, but we're only just getting started.

Now that we have our settings file (in my case, "rpc counters.htm"), we can perform a few little tricks. First, since it's HTML, we can actually open this settings file with Internet Explorer. Unless you've weakened the security settings for IE, you'll need to click "Allow blocked content", but do that and you see Perfmon embedded within Internet Explorer:

Notice that Perfmon includes not just the counter list I added before, but visible data points as well (which was saved in the settings file). But more importantly, this is a fully functioning instance of Perfmon. Notice the two green buttons in the menu bar at the top of the Perfmon instance – the one on the left (similar to the "Play" button on a CD or DVD player) switches the display to live data, while the second (the "Skip Forward" button) leaves the display paused but updates the data to the present moment.

The green "Play" button has changed to a blue "Pause" button, and many of the other buttons have also been enabled as well (including add and remove counters).

"This is nice," you may say to yourself, "but what good does it do?" Well, for one thing, you can select a specific set of counters, save the settings file, and then distribute the settings file to your teammates so that they can open that same set of counters. This is very useful if you have a large set of counters and want to make sure that everyone's looking at the same data.

Where the "Save Settings As" option really becomes useful is when you're working with performance logs (BLG files). In this case, I've captured performance data using a custom Data Collector Set, and the results of the data are saved in C:\Perflogs\Admin\New Data Collector Set\DC1_datetime.log. I switched back to the Performance Monitor tab, and selected View Log Data from the action menu (you can also press Ctrl+L to do the same thing).

On the Data tab, I select all four counters from the log file and add them into the list to display.

Because I don't have very much data in the BLG, the resulting display isn't terribly exciting. But it's not the display that I'm concerned with here – it's what I can do with the data I selected. Again, I right-click and select "Save Settings As" and save the list of counters to another HTML file. [Side note: when you select "Save Settings As" when viewing data from a BLG, other options become available, including Save Data As, which gives you the option to reduce the size of an existing BLG by saving only a subset of data points.]

However, when you open this second HTML file, you'll notice that things look a little different. The counter names are prefaced by the server name:

My lab machine is named DC1, but if I want to use this on a performance log I collected from DC2, all I need to do is a simple find-and-replace in the HTML file, open the appropriate saved log (View Log Data), and then perform the same copy/paste trick listed above. Again, Perfmon will add all of the relevant counters directly into the display. That means that you can create the list of counters once and use that same list for every single BLG you want to review. Just change the name of the server within the HTML file for each server, then paste the contents.

To summarize, Perfmon allows you to save and load sets of performance counters, and you can use this functionality to make your performance life a little easier. By saving the settings to disk, you can ensure that you use the same list every time, even if you've closed Perfmon. You can launch Perfmon from within Internet Explorer using a saved settings file, which helps ensure consistency so that everyone uses the same counters. Last, you can use a settings file as a template to view the same set of counters from different BLG files from different servers.

Hopefully these tricks help you become more efficient in your use of Perfmon. Let us know in the comments!