Remote Desktop Connection Manager (RDCMan) is a great tool to consolidate multiple RDP connections into a single window to prevent desktop clutter.
Update 19-11-2014: RDCMan 2.7 is now available. Please see here.
The tool can be downloaded from the Download Centre.
There are a couple of things worth noting about the tool:
It will install into the x86 Program Files folder on a x64 machine:
C:\Program Files (x86)\Remote Desktop Connection Manager
Do not save your custom RDG files in the installation folder, just in case your local workstation dies and the file is gone. I always keep my .RDG files in a subfolder of My Documents, which is a redirected folder to a file server.
The RDG files are portable, and you can share them within your organisation. For example, when you get a new admin give them a copy of the RDG files and they are able to review your list of servers and get connected easily – assuming they have the permissions….
The help file is located in the same directory - unsurprisingly this is called help.htm
Finally and most importantly, please say a big thank you to Julian Burger the developer who wrote this and David Zazzo for working to get it released!!
Cheers,
Rhoderick
Some featured white papers on the Exchange TechNet site:
Technical White Papers for Exchange Server 2010
White Paper: Understanding the Relative Costs of Client Access Server Workloads in Exchange Server 2010
http://technet.microsoft.com/en-us/library/ff803560.aspx
White Papers: Exchange 2010 Tested Solutions
http://technet.microsoft.com/en-us/library/gg513520.aspx
In the Exchange 2003 world and below, those administrators looking to automate and control the behaviour of MAPI profiles on user’s desktops quickly became familiar with tools like:
For a refresher on such joys of .PRF files etc. take a peek at:
Whitepaper: Configuring Outlook Profiles by Using a PRF File
Automate Outlook Profile Creation Using PRFPATCH
The Exchange Profile Update tool
Owch, those were some painful days! Thankfully with Exchange 2007/2010 and Outlook 2007/2010 we are able to move on from such tasks. Exchange 2007 introduced the Autodiscover web service which is used by Outlook 2007 and above to automatically configure the required Outlook settings. This not only includes the initial connection to Exchange but also if the administrator then makes changes to URLs then Outlook will detect and apply such changes. This is a great boon to administrators and will reduce user & configuration issues.
Sounds good does it not?
It is; but I typically see this as one of the most misunderstood and misaligned services in Exchange. As far as I am concerned if Autodiscover is broken, then Exchange is broken in your environment and needs immediate remediation.
Take 10 minutes to carefully read through these links:
Exchange 2007 -- White Paper: Exchange 2007 Autodiscover Service
Exchange 2010 -- Understanding the Autodiscover Service
White Paper: Understanding the Exchange 2010 Autodiscover Service
You’re back? Good reading – right? If you didn’t read it shame on you
The key issue that I encounter when working on Exchange engagements is the perception that Outlook ONLY uses DNS for Autodiscover. If your workstation is domain joined and you are connected to the internal network you should NOT be using DNS to determine which server you will contact for Autodiscover, this is a very common falsehood. In actual fact you should be leveraging a Service Connection Point (SCP) in AD. The SCP is published into AD when a CAS server is installed. This is done automatically by the Exchange setup routine. You can see the value in ADSIEDIT as the serviceBindingInformation attribute and in PowerShell using the Get-ClientAccessServer –AutoDiscoverServiceInternalUri parameter. For example in my lab, the serviceBindingInformation attribute is found under the server object here:
CN=EXCH-1,CN=Autodiscover,CN=Protocols,CN=EXCH-1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Tailspintoys,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tailspintoys,DC=com
While we are here, you will also see the keywords attribute. This is the underlying attribute that holds the information set buy Set-ClientAccessServer –AutoDiscoverSiteScope. The two attributes can be seen here
By default this will be the FQDN of the server. This should be changed to a Load Balanced URL as per your Exchange design to achieve HA.
To show this in a diagram:
Outlook will build either (but not both) a list of CAS servers in-site or out of site. The AutodiscoverSiteScope value is used to determine site membership. It will the sort them and connect to the 1st one in the list. This means that you will typically connect to the CAS that was installed first. If Outlook fails to contact any CAS server based off its SCP look-up then it will fall back to DNS.
For external Outlook clients in Starbucks, they are not able to directly contact AD (I sure hope that you don’t have a DC exposing 389 TCP to the Internet…..) and thus will use DNS to locate the Autodiscover endpoint. This is illustrated here:
A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service
http://support.microsoft.com/?kbid=940881
Prior to this update Outlook would perform these DNS queries by default:
With this update installed the SRV query is added:
As an example:
GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml
This fails.
Note: If you Internet facing DNS provider does not support SRV records then you cannot use this feature.
You may not want your users to see the redirect warning as mentioned in step 5 above. if so then please review :
You cannot suppress the Autodiscover redirect warning in Outlook 2007
http://support.microsoft.com/kb/956528
(Note the change in Registry path for the recent updates)
BONUS CHAT
There are other really interesting things you can do with the registry to tune and alter the default behaviour of Autodiscover on the Outlook client machine.
The registry key for Outlook 2007 is:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
The registry key for Outlook 2010 is:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\AutoDiscover
By changing the values below you alter the default behaviour of Autodiscover.
Value name: PreferLocalXML Value type: DWORD Value data: 0 or 1
Value name: ZeroConfigExchange Value type: DWORD Value data: 0 or 1
DisableAutoStartup
Value type: DWORD Value data: 0 or 1
Value name: ExcludeHttpRedirect Value type: DWORD Value data: 0 or 1
Value name: ExcludeHttpsAutodiscoverDomain Value type: DWORD Value data: 0 or 1
Value name: ExcludeHttpsRootDomain Value type: DWORD Value data: 0 or 1
Value name: ExcludeScpLookup Value type: DWORD Value data: 0 or 1
Value name: ExcludeSrvRecord Value type: DWORD Value data: 0 or 1
To expand on the Local XML option, when Autodiscover functionality is available on your e-mail server, Outlook 2007 initiates the Autodiscover process to obtain server connectivity settings. Once a server that supports Autodiscover is located, the server returns XML data that provides the information needed for Office Outlook 2007 to automatically configure your e-mail account.
The Local XML registry value allows you to specify a local path to an .xml file that Outlook 2007 can additionally use to configure its e-mail account. The name of the registry value is the host name of the e-mail address that is provided to Outlook. In the following example, the specified path to the .xml file would be used for any e-mail addresses ending in contoso.com. The path in the first case is to a file named Autodiscover.xml located on a server named server1. A local option is then shown.
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
Value Type: DWORD
Name: contoso.com
Data: \\server1\share\autodiscover.xml
or
Data: C:\autodiscover.xml
See http://technet.microsoft.com/en-us/library/cc837949(office.12).aspx for additional registry entries that you may wish to deploy with the Outlook client.
Exchange 2007 & 2010 use a different message routing design than Exchange 2003. This is an important aspect to understand when transitioning from Exchange 2003 upwards due to the change in behaviour.
TechNet has articles that discuses these concepts :
Exchange 2010 http://technet.microsoft.com/en-us/library/aa998825.aspx
Exchange 2007 http://technet.microsoft.com/en-us/library/aa998825(EXCHG.80).aspx
Exchange 2003 http://technet.microsoft.com/en-us/library/aa998800(EXCHG.65).aspx
Exchange 2007 and 2010 base their routing topology off the defined AD site design, and do not carry forward the Exchange 2000/2003 concept of Routing Groups (though mail can still be delivered to servers in the older Routing Groups during a transition).
When sending a message from one Exchange site to another, the Hub will determine the least cost route and only use this one route. This means:
Determining the least cost route can be easily determined if you have site link costs that sum up to different totals. But should you design an Exchange 2007 environment that has two paths between sites that has the same cumulative site cost it may lead you to think that both connectors will be used in a load balancing scenario. Still in this case a single least cost path will be determined. Having two paths with the same cost does NOT mean that both connections will be used! Least cost routing really does mean least cost, i.e. use the one that has the lowest cost and only that least cost route. let’s dig into this a little.
Here is an example of an Exchange organisation that has 5 sites. The relevant cost of the link is show on the respective segment.
Now, let’s review three examples to see how the message path is determined:
Example 1 A message that is being relayed from Site A to Site D can follow two possible routing paths: Site A-Site B-Site D and Site A-Site C-Site D. The costs assigned to the IP site links in each routing path are added to determine the total cost to route the message. In this example, the routing path Site A-Site B-Site D has an aggregate cost of 20. The routing path Site A-Site C-Site D has an aggregate cost of 10. Routing selects path Site A-Site C-Site D.
Example 2 A message is being relayed from Site B to Site D. There are three possible routing paths: Site B-Site D with a cost of 15, Site B-Site E-Site C-Site D with a cost of 15, and Site B-Site A-Site C-Site D with a cost of 15. Because more than one routing path results in the same cost, routing selects the routing path Site B-Site D. This has the least number of hops.
Example 3 A message is being relayed from Site A to Site E. There are two possible routing paths: Site A-Site B-Site E with a cost of 10, and Site A-Site C-Site E with a cost of ten. Both routing paths have the same cost and same number of hops. The alphanumeric order of the Active Directory sites immediately before Site E is compared. Site B has a lower alphanumeric value than Site C. Therefore, routing selects the routing path Site A-Site B-Site E.
After the least cost routing path has been determined, Exchange 2007 & 2010 routing does not consider alternative routing paths.
Why did Example 3 behave the way that it did? Multiple factors come into choosing the least cost path which include:
This can be summarised as:
So, least cost really does mean least cost!
EDIT: This feature is now live in the Exchange 2010 SP2 RU3 build of Exchange. Will add a post about this change at a future date.
This post is to clarify that a previously discussed feature that was intended for Exchange 2010 SP1 is not in the SP1 final build.
The feature I am referring to is the allow/block cross site RPC Client Access connections. This sometimes comes up in workshops and discussions with clients regarding CAS & DAG interaction. There are numerous blogs (http://tinyurl.com/4yysfp5) and a couple of books that describe the feature.
If you read the current TechNet documentation on the Set-DatabaseAvailabilitygroup cmdlet then you will see that the feature is listed as reserved. This is available here:
Set-DatabaseAvailabilityGroup
These are oldies but goodies. Posting links as requested.
Update: I Created a Deep Zoom of the posters so that it is easy to scroll around in a browser or mobile device. Click the toggle button at the bottom right hand corner to enter full screen mode.
Download Link.
One of the great changes to Exchange 2010 SP1 was that a DAG static IP address can be set using the EMC. Prior to this in RTM the EMS had to be used to set a static IP. An example of this would be:
-DatabaseAvailabilityGroupIpAddresses 192.168.2.150
(note this is a single line that may wrap)
Scott has this and many other great details on his blog here:
http://blogs.technet.com/b/scottschnoll/archive/2010/04/10/new-high-availability-features-in-exchange-2010-sp1.aspx
If you do not subscribe to his RSS feed, I’d highly recommend that you do so – the feed is here: RSS for posts
Anyway, back on target red leader!
In the SP1 EMC to revert the DAG to using DHCP, simply remove all the IP Addresses that were assigned.
But how can you revert a DAG back to using DHCP in EMS you may ask?
Set-DatabaseAvailabilityGroup -Identity TailspinDAG1 -DatabaseAvailabilityGroupIpAddresses 0.0.0.0
Full documentation for Set-DatabaseAvailabilityGroup is here:
Set-DatabaseAvailabilityGroup.
As a Microsoft Exchange Server focused Premier Field Engineer I spend a considerable amount of my time with customers at their work place and also when they attend training courses and workshops that I deliver. Naturally people want to talk and learn about the cool new features in Exchange 2007 and Exchange 2010, which is great as it shows their underlying passion in the product. What they often do not want to cover is what PowerShell is and how they can use it to enhance their productivity as an Exchange administrator. Since I will be covering various Exchange topics in a series of upcoming articles I wanted to ensure that there was adequate coverage of PowerShell’s underpinning concepts. This article will focus on underlying PowerShell constructs rather than diving straight into the specifics of Exchange and PowerShell.
For part two please click here.
For part three please click here.
Our journey begins with Exchange 2007 which was the first version of Exchange to support PowerShell. Exchange 2007 was a ground breaking product in many ways. It was the first Microsoft server product to fully embrace the 64 bit world (x64, not Itanium), it shipped on a DVD not a CD, had Unified Messaging capabilities, a simplified GUI called the Exchange Management Console (EMC) and the installer also added a shortcut to something called the Exchange Management Shell (EMS). It can be overlooked but EMS is the underpinning of the EMC and for the first time in Exchange it was possible to do more in the shell/script environment rather than the GUI. Additionally it became dramatically easier to perform command line and script operations against Exchange and mailbox enabled users.
If you take a trip back to prior versions of Exchange, there were multiple methods to code and script against Exchange. For the regular Exchange administrator, who does not have a programming background, such methods tended to be avoided due to their inherent complexity. As an example of this, consider this sample code to list Exchange server object(s):
Const ComputerName = "LocalHost" Const WMINameSpace = "root/cimv2/applications/exchange" Const WMIInstance = "Exchange ServerState" Set ExchangeList = GetObject ("winmgmts:{impersonationLevel=impersonate}!//" & - Computer Name & "/" & - WMINameSpace).InstancesOf (WMIInstance) For each ExchangeServer in ExchangeList Wscript.Echo "Name: " & ExchangeServer.Name Wscript.Echo "Version: " & ExchangeServer.Version Next
The Exchange administrator would need to refer to the SDKs to work out how to discover the capabilities of the interfaces provided to them. Not a pleasant task! In addition there were multiple interfaces, and you would need to choose between them, selecting the most appropriate for the task at hand. Thus you would have to become familiar with ADSI, OLE DB, ADO, CDO and CDOEXM if you want to have complete programmable access to Exchange 2000 data structures. These interfaces performed the following functions:
Exchange 2007 and PowerShell freed the Exchange administrator from these shackles and allowed them to use a shell environment that was designed for administrators from the ground up. The previous sample code can be replaced with the following in PowerShell:
Get-ExchangeServer
The command is definitely more succinct; has a clearer intent than the previous sample and is easy to remember. Currently there are two versions of PowerShell, 1.0 and 2.0. Since PowerShell 2.0 is supported on Exchange 2007 SP2 and is required for Exchange 2010 we will focus on this version. The Windows PowerShell section in the Exchange Server Supportability matrix contains these details amongst may other great pieces of information. To install PowerShell 2.0 in an Exchange server (assuming that you are not using Windows 2008 R2 as it has PowerShell contained 2.0 in-box) please refer to the detailed documentation on TechNet.
Of course all the Exchange 2007 readers will have SP3 deployed now since that is the only supported version of Exchange 2007 at this time, right? If not, then it’s high time to verify SP3 in your lab and then fire up your change management tool! Microsoft provides a detailed search tool, which will quickly show the current support status for a given product.
The PowerShell command mentioned previously, Get-ExchangeServer, is an example of a cmdlet (pronounced command-let) in PowerShell. Note the Verb-Noun structure which indicates what the cmdlet will do and to what entity. This assists in making the cmdlets self-describing. As an example:
Get-Mailbox Retrieves object’s information
Set-Mailbox Sets property on the object
Remove-Mailbox Deletes the object
PowerShell has strict design rules to ensure that there is a consistent and clear approach to the nomenclature and syntax used. This is not the case with the various cmd.exe utilities which demand switches with varying syntax such as a hyphen, space, forward slash or back slash and are not typically tolerant of mistakes. Note that you can still run these cmd.exe tools and utilities in PowerShell. PowerShell is not only built on top of the .NET Framework, it is fully integrated with .NET. The cmdlets are .NET specialized classes, and in addition it is possible to leverage the other .NET classes over and above those that are in cmdlet form. For those with a VBScript background you may remember that VBscript was limited to a subset of the .NET classes and could only access those with a defined COM interface. As an example of this fantastic capability, Jose Barreto demonstrates how to leverage the .NET classes to manage ACLs on NTFS files.
Administrators are typically very familiar with the concept of pipelining, i.e. passing the output of one command to another to smooth the administrator’s workload. This is present in Linux and also the cmd.exe prompt in Windows. While on the surface it may look like PowerShell is doing exactly the same as those other shells, this is not the case. The core difference is that the other shells pass unstructured text between their commands whereas PowerShell passes structured .NET data objects down the pipeline. This is a critical concept to understand as it is this that raises the bar on what PowerShell is able to accomplish. The pipeline symbol is | (for those with English UK keyboards it is not the broken pipe ¦ ), and can be used as follows: cmdlet1 | cmdlet2
Get-Mailbox “User1” | Set-Mailbox –ParameterToChange
One of the fundamental differences between a command line environment and a GUI is that of discoverability. In a GUI, one can become aware of features, settings, capabilities and also how to make changes to the above simply by navigating through the interface. In a command line this discovery is not possible in the same way since it is harder to make the leap from one topic to another to facilitate this learning. That being said PowerShell does have the capability to assist you without having to resort to using Bing to find the relevant command! How to achieve this? It’s a matter of remembering a few initial commands that can then be used to learn and discover the remainder of the command line environment.
What you need to remember:
Get-PsSnapin
Get-PSDrive
Get-Command
Get-Help
Get-Alias
Get-Member
Let’s look at these in turn!
PowerShell can be thought of as an automation framework, though PowerShell by itself is like an empty Management Console (MMC).
The MMC has great potential but for that to be realized, functionality needs to be added in the form of snap-ins. Adding in the Local Users and Groups snap-in allows the MMC to be used to manage the local user objects.
Using the MMC with the Snap-in added, we can set the focus on the Groups container:
The same can be seen in PowerShell. To do this, open a PowerShell window and run the command:
Get-PSSnapin
It will return the currently loaded Snap-ins within the PowerShell. This is a view of PowerShell 2.0 on a Windows 7 desktop.
Without a snap-in, PowerShell would not be able to achieve much. A key concept is how the administrator will have the data presented to them. We are familiar with the command prompt showing C:\ D:\ and so on; PowerShell provides this and more! PowerShell will abstract other locations and present them in a unified framework. For example you can navigate the registry, certificate store and others as if it were a simple file system! To see these drives use the command
Get-PsDrive
To change to the HKEY_LOCAL_MACHINE PSDrive simply enter:
CD HKLM:
Then press enter.
To return, enter
CD C:
Then press return.
You may have noticed the Providers column in the Get-PsDrive capture. A provider is .NET code that renders the data in a specialized place and makes it available so that it can be easily seen and managed. To see the available providers run Get-PSProvider:
What about the commands we can run? This is the good stuff, but how do we discover them? PowerShell contains the cmdlet Get-Command. This will return commands that match your specified criteria. Without parameters, "Get-Command" returns all of the cmdlets and functions in the current session. "Get-Command *" returns all Windows PowerShell elements and all of the non-Windows-PowerShell files in the Path environment variable. Get-Command has excellent filtering capabilities and you can leverage searches like the examples below:
One you have identified the cmdlet that you want to leverage, typically you will want to read a bit more about it to determine the supported options, etc. Since PowerShell is self-describing, all cmdlets contain help information. To access this information we use the Get-Help cmdlet. So to view help information on the Get-Mailbox cmdlet run:
Get-Help Get-Mailbox
It is also possible to filter and choose the exact type of help that you want to read. When running the Get-Help cmdlet, we can add an extra parameter to tell PowerShell what we want.
As an example, returning the different levels of help on the Get-Mailbox cmdlet would look like this:
Get-Help Get-Mailbox –Full
Get-Help Get-Mailbox –Detailed
Get-Help Get-Mailbox -Examples
Though not directly related to the cmdlets that show the PowerShell environment, PowerShell has an outstanding feature that ensures that you are on the right path when entering commands, as typos will cause things not to work too well! PowerShell supports auto completion of entered cmdlets to assist with typing, and also to minimize mistakes. To use the feature enter the start of the command, I like to type enough that PowerShell can filter it down to a nice small subset, then press the tab key to cycle through the options. For example, if I enter the following:
Then press tab, the command changes:
Note that the command completed without having to type the remaining text, and it also became capitalized. This is critical to note as it tells me that PowerShell recognized the command. If the case did not change or autocomplete did not work, then I have a typo that I need to correct. In addition to autocomplete support for cmdlet names, there is also support for completing and discovering the parameters available to each cmdlet. To demonstrate, I will add a hyphen after the Get-Command:
Then press Tab:
Pressing Tab again moves to the next parameter:
If you keep pressing tab, PowerShell will cycle through all the parameters in a loop. To reverse the direction, use Shift + Tab to go back.
PowerShell also supports the concept of aliases, where a cmdlet can be invoked using a different name. This can shorten the amount of typing, and also provides a migration path to PowerShell for people transitioning from other environments. Administrators with a Linux background will find that there are predefined aliases for MAN and LS, which are for the Get-Help and Get-ChildItem cmdlets respectively. But such predefined aliases are not limited to those with a Linux upbringing, they are also for Windows administrators. In fact in PowerShell when you run commands like DIR, CLS, DEL you are actually using an alias. To see the mapping between the DIR alias and the underlying cmdlet, run:
Get-Alias DIR
To see all defined Aliases, run
A common question at this point is what can we actually do to the various objects that PowerShell interfaces with, be it an NTFS folder or Exchange mailbox. Again due to the self describing nature of PowerShell this information is readily on hand and is retrieved with a cmdlet. The cmdlet in question is:
Get-member
In the following example we want to see all of the properties and methods that are available on a folder called C:\Temp\Hyper-V.
Note that we are retrieving an object representing the Hyper-V folder and then passing it down the pipeline to the Get-Member cmdlet. The Get-member cmdlet then enumerates the properties and methods that are available. For the non-programmers reading this, they may be wondering about the difference between a property and a method. They can be readily likened to a noun and a verb in language, i.e. a description word and a doing word. When applied to a person, a property could be the person’s name, address or ice cream preference. Similar methods applied to a person could be go buy ice-cream, sit down or drink beer. Some properties are read only whilst some are writable, this will vary depending on the exact object you are reviewing.
We have reviewed some of the history with Exchange scripting and automation and demonstrated how you can start to discover the various commands in PowerShell. Investing time in your skillset and learning PowerShell is guaranteed to repay itself over and over. Not only can you perform operations in PowerShell that would have been harder using some traditional toolsets, but PowerShell adoption is spreading rapidly. Exchange, SQL, DPM, VMM, Windows amongst many others now embrace PowerShell.
In summary remember the following commands and they will assist in discovering the correct information in PowerShell.
If you have comments or feedback about this or any other content posted, please leave a comment. Comments suggesting future topics are always appreciated too!
Perhaps the most significant change between Exchange 2007 and Exchange 2010 is the move to channel Outlook connectivity through the CAS role. In Exchange 2007 Outlook would connect to the mailbox role, whilst other protocols (POP, OWA, IMAP etc.) would leverage the CAS role.
In Exchange 2010 this means that we now find two new services installed on the CAS role:
These services are responsible for handling the Mail, NSPI and RFR client access connections from Outlook. The mail RPC end point is still present in the Information Store but accepts connections only from CAS. Public folder access is direct to the mailbox role, but Outlook connects to the RPC Client Access service on the mailbox role and not directly to the Information Store.
Note that the RPC Client Access Service is also found on the Mailbox role as well, as explained above.
For a full listing of the services installed by Exchange 2010 setup please see:
Overview of Services Installed by Exchange Setup
References for RPC Client Access:
Understanding RPC Client Access
Understanding the Address Book Service
Exploring Exchange 2010 RPC Client Access service
My good friend Dan wrote a great blog entry about automating the installation of the required Windows OS prerequisites for an Exchange 2010 install. You can read it here.
Over and above this, Exchange 2010 SP1 adds a new setup switch
/InstallWindowsComponents
Exchange 2010 SP1 Setup has been improved to allow you to install the required Windows roles and features. If you select the option to install Windows roles and features, progress is shown and the appropriate roles and features are installed. If a reboot is required, you will have to reboot the server and launch Setup again. When Setup is launched again, Setup will resume where it left off. If you don’t select the option to install Windows roles and features, you can manually install the Windows roles and features and continue Setup after the prerequisites are met.
For example, to install the CAS,MBX and HUB roles auto-magically run:
setup.com /Mode:Install /Roles:Mailbox,ClientAccess,HubTransport /InstallWindowsComponents
And to do the same with less typing (though the /M switch could also be dropped):
setup.com /M:Install /Roles:M,C,H /InstallWindowsComponents
TechNet has the full prerequisites listed here.
As an added bonus, you can also do this on the upgrade from Exchange 2010 RTM to SP1:
Setup.com /m:upgrade /InstallWindowsComponents
The Exchange 2010 RTM (Release To Manufacturing) build has now reached the end of its support lifecycle. Customers should upgrade to SP1 to continue to receive support (amongst many other good reasons!).
The Exchange 2010 lifecycle can be viewed here:
Full details about the Microsoft lifecycle policy can be viewed here
http://support.microsoft.com/lifecycle/
I would also encourage you to sign up to the quarterly lifecycle update newsletter to ensure that you have the knowledge to keep all of your products in a supported state, and continue to receive the support that you are entitled to!