Sunday, July 27, 2014

Exchange 2010 (SP3) - Migration - some remarks about SCPs (service connection points)

Introduction

What follows is not a step in the migration process to Exchange 2010 but rather some remarks concerning a possible (and essentially hypothetical) issue with Service Connection Points (SCPs). Unless some bizarre factor alters the normal state and order of the SCPs, there is nothing that needs to be done at this level. For details, read what follows...


***

Will the simple installation of Exchange 2010 in an Exchange 2007 environment affect the users?

This is an important question.  Besides interruption of normal business operations, we want to avoid the distraction of popups indicating something is wrong with "some certificate".

One concern voiced somewhere (I do not recall exactly where) was the creation of a SCP (Service Connection Point) record for the new Exchange 2010 server in Active Directory.

Note: what follows concerns domain members that can access Active Directory locally or "onsite". The process is different for remote clients (users accessing their email from home or on the road).

***

When Outlook (since version 2007) attempts to connect to Exchange, it will first consult a domain controller and seek a SCP that indicates the URL of a client access server with autodiscover services. These services will configure the connection to the client mailbox automatically. This is the process we can observe when we open Outlook for the first time.

I wrote "URL" but the autodiscover "URL" is defined with the Set-ClientAccessServer cmdlet and the -AutoDiscoverServiceInternalUri parameter, for example:

Set-ClientAccessServer -Identity "CAS1" -AutoDiscoverServiceInternalUri "https://mail.contoso.com/autodiscover/autodiscover.xml"

Remark the Uri at the end of the -AutoDiscoverServiceInternalUri parameter. By default, the name of the CAS would be in the position of "mail". If we follow best practices, we would replace it (as in the above example) with a term like "mail". Moreover, the associated record in DNS (not to be confused with the SCP record - these are totally different concepts) would designate some sort of load balancer that forwards client requests to one of two or more Client Access Servers. 

When a new Exchange Client Access Server is installed, a SCP record is created for it in Active Directory.

That SCP object (record) can be found here:

CN=Name of Exchange server,CN=Autodiscover,CN=Protocols,CN=Name of Exchange  server,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=organization Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

For example:



We can right-click on the folder with the servername, select "Properties", and see the SCP details under the Attribute Editor tab.

By default, the “serviceBindingInformation” attribute designates the CAS with an URL like this:

"https://ex-server-1.contoso.com/autodiscover/autodiscover.xml"

In theory, these default settings could hypothetically cause the following problem if the SCP of the new Exchange 2010 server was selected.

If the certificates used to validate the server do not include the name of the server itself, an error message will display, stating that the name of the server does not match the name (or names) on the certificate. This causes confusion for the user and calls to the help desk. Users could opt to trust the certificate without understanding the possible implications. In this case, we know the server is one of our servers and can be trusted. In general, however, it is a security risk to interact with servers whose identity cannot be validated.

In practice, it appears that this scenario should never occur since the client should select the "first" SCP record (if there is more than one).

Note: we assume that the first SCP record has been configured as appropriate with the Set-ClientAccessServer cmdlet as mentioned above, something like "mail" instead of "CAS1" (and with a corresponding record in DNS pointing to a load balancer).

So I examine the location indicated above (either ADSIEdit or Active Directory Sites and Services - with the "Show Services Node" option - can be used).

I have two servers: EX1 (the Exchange 2007 server) and EX13-1 (the Exchange 2010 server):




Next, I must expand the respective folders to reach the SCP:




Once again, we right-click on the folder with the servername, select "Properties", and see the SCP details under the  "Attribute Editor" tab:




OK, the folder for EX1 is above the folder for EX13-1. Can we conclude that the SCP record contained in this folder is the "first" SCP record?

Other sources state that the "oldest" SCP record will be selected, or the SCP record that was "created first".

So I compare the "whenCreated" value of each of the SCP records. As we can see (last entry in the screenshot above), the SCP record for EX13-1 was created on 7/9/2014. The SCP for EX1 was created before that date.

***

Finally, I have observed from experience that clients apparently do select the oldest SCP record since no error message is displayed when they access their email. This is true even before I change the client access URLs on the Exchange 2010 server so they match the names on the certificate used to validate access.

***

In conclusion, simply installing Exchange 2010 should have no effect on normal business operations.


EDIT

After having tested this, I confidently installed Exchange 2010 in a production environment. The plan was to import and enable a UCC/SAN certificate that evening. However, we had to concentrate on the resolution of a problem with an update and thought we could safely wait to install the certificate.

What happened the next morning?

Certificate warnings for users when they opened Outlook...

We installed the certificate immediately and the warnings no longer displayed when users opened Outlook.

I'm not sure why this happened. I suspect that, although the oldest SCP record is selected (there seems to be consensus on this), the autodiscover information may include references to all or any one of the servers, without distinction.

I ran the autoconfiguration test (press Ctrl, right-click on the Outlook icon in the taskbar) and the references to the Exchange 2010 server were for OWA and OAB (everything else - EWS, UM, etc. - was for the Exchange 2007 server).

Lesson learned: import and enable the UCC/SAN certificate as part of the installation process of Exchange 2010.

Saturday, July 26, 2014

Exchange 2010 (SP3) - Migration - Part 3 - CAS Array

I already presented the CAS Array in a previous blog post, as well as some references to other sources:


As mentioned in that post, there is really no reason to specify "Exchange 2010 CAS Array" since the CAS Array does not exist in any other version of Exchange.

Moreover, the CAS Array is not specific to a migration. It could be configured for a new Exchange installation ("green field") as well.

Even so, I mention it here because it is a "Best Practices" step for most Exchange implementations. Yes, we could use Exchange without a CAS Array. Indeed, when there is only one Exchange server, the CAS Array provides no additional functionality. On the other hand, if we want high availability or load balancing, the CAS Array can be a crucial element. Even if we only have one Exchange server, it can be useful to create a CAS Array all the same, since it can facilitate the addition of another Client Access server, or the migration to a new CAS.

So, without repeating all of the previous post referenced above, I'll present the two steps of the creation of a CAS Array below.

First, we create the array (which is simply an object in Active Directory and not a physical or virtual device) with the following cmdlet:

[PS] C:\>New-ClientAccessArray -Name CAS-ARRAY-1 -Fqdn cas-array-1.mynet.lan -Site Default-First-Site-Name

As you can see, we need to specify the name, FQDN and the site of the CAS Array. Unlike Database Availability Groups (DAGs) for the Mailbox Role, a CAS Array cannot span two or more Active Directory sites (one CAS Array per site).

Then, in the DNS Management Console, or with dnscmd at the command line, we associate the CAS Array's FQDN with an IP address:

PS C:\> dnscmd dc2.mynet.lan /recordadd mynet.lan cas-array-1 A 10.0.0.23

At this point, the IP address is that of the first Exchange 2010 server that I have installed. As soon as I have my load balancer configured, I will associate the CAS Array FQDN with the virtual IP (VIP) or the load balancer.

If I only intend to have one CAS (at least for the time being), I would leave the CAS Array FQDN associated with the IP address of that server.

Sunday, July 20, 2014

Exchange 2010 (SP3) - Migration - Part 2 - Certificates

Certificates have an important role in the Exchange messaging system. They validate the server to which users connect when accessing email (Client Access role). They are part of the encryption process that protects access to the email server and also (optionally) the sending and receiving of messages between servers on the Internet (Hub Transport role).

Although other options are possible (self-signed certificates, use of a local certificate authority), the best practice consists in obtaining a certificate from an external third party certificate authority. Unlike self-signed or locally issued certificates, these certificates will be trusted by all clients, domain members or not.

If we have selected this option (third party certificate), we probably already have such a certificate on the Exchange 2007 server (or servers). But migration from Exchange 2007 to Exchange 2010 usually requires the purchase of an new certificate that will replace this existing certificate.

Why? Because at some point, we will redirect both mail flow and client access operations to the Exchange 2010 server instead of the 2007 server  (to "keep it simple", I will assume, for the moment, that there are only two servers). This involves changing DNS records and Client Access URLs.

In my case, I use the following name:

mail.mitserv.net

At this time, the associated DNS record points to the Exchange 2007 server.

What will happen when we point that record to the Exchange 2010 server? How will clients find the Exchange 2007 server then?

I should clarify that unless the migration can take place quickly (overnight or over the weekend), there will be a period of "coexistence" during which users will access either the 2007 or 2010 server. This all depends on one factor: has their mailbox been migrated yet, or not?

We also need to remember that if the mailbox is on an Exchange 2007 mailbox server, there must be an Exchange 2007 client access server in the same site, and likewise for a mailbox on an Exchange 2010  server. In other words, an Exchange 2007 CAS cannot provide client access to a mailbox on an Exchange 2010 mailbox server and vice versa.

Consequently, we must have a mechanism allowing the Exchange 2010 server to redirect clients with a mailbox on an Exchange 2007 server to an Exchange 2007 CAS (which may be the same server as the mailbox server, of course).

This is accomplished by changing the appropriate URLs on the Exchange 2007 server to:

legacy.mitserv.net

instead of...

mail.mitserv.net

Of course, the domain name will vary from organization to organization. Moreover, the use of the word "legacy" is a convention - we could use another term. At any rate, we must change the DNS records as well so they reflect the new locations.

But what does this have to do with certificates?

The name "legacy.mitsev.net" must be added to the subject alternative names of the certificate used to validate the identity of the Client Access server. Since the Exchange 2010 server needs a certificate regardless, the preferred method is to obtain a brand new certificate from the external third party authority, import and enable the certificate on the Exchange 2010 server, then export the certificate and import and enable it on the Exchange 2007 server. Yes, we want the same certificate on both servers and then on any other Exchange 2010 servers that may be added later.


Create New Certificate Request

First, we create a certificate request on the Exchange 2010 server. We have the option of using either the GUI or Powershell. This is an improvement from Exchange 2007 where there was only the Powershell option. I'll simply use the familiar (for me at least) Powershell option.

Here is the command:

[PS] C:\>$Data = New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=CountryCode, s=My State, l=MyCity, o=My Organization, CN=mail.mitserv.net" -DomainName mail.mitserv.net, autodiscover.mitserv.net, legacy.mitserv.net -Keysize 2048 -privatekeyExportable:$true

[PS] C:\>Set-Content -path "C:\Certs\mitserv.csr" -value $data

I wrote "familiar" but, in fact, the New-ExchangeCertificate cmdlet used with Exchange 2010 is different. The -path parameter no longer exists and we have to use the Set-Content parameter to create the request file.

--------------------------------------------------------------
Instead of the Set-Content cmdlet, we could use the following:

[PS] C:\>$data | Out-File C:\Certs\mitserv.csr
---------------------------------------------------------------

For comparison, this is what the command looked like in Exchange 2007:

New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=CountryCode, s=My State, l=MyCity, o=My Organization, CN=mail.mitserv.net" -DomainName mail.mitserv.net, autodiscover.mitserv.net, legacy.mitserv.net -Keysize 2048 -privatekeyExportable:$true -path "C:\Certs\mitserv.csr"

This produces a text file at the location indicated in the -path parameter.

Note: the file extension for the request file can be .csr or .req or .txt

Note: if you want to use the certificate on multiple servers, make sure the value of the -privatekeyExportable parameter is "true". If not, the certificate cannot be exported (with its private key) and used elsewhere.


Submit the Request to the Certificate Authority

Although the exact interface will differ between certificate authorities, the general procedure is the same.

We open the .csr file, in Notepad for example, highlight the content and copy.

Note: the content will look like this (truncated):

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEMDCCAxgCAQAwZDEZMBcGA1UEAwwQbWFpbC5taXRzZXJ2Lm5ldDEWMBQGA1UE
CgwNRGF2aWQgTWFjaHVsYTEPMA0GA1UEBwwGQWxiYW55MREwDwYDVQQIDAhOZXcg
[...]
KmkHv/J3wJBIPMFzYA958ix3e09jnzTGmCSwMOPSDDTWj0Z7nGQOICva8+9HEy6m
bjYs/lpEXWpY3C2q/bYrbFTXO60=
-----END NEW CERTIFICATE REQUEST-----

Note: include the Begin and End header/footer in the copy and paste operation.

We would then paste the content in the text box provided by the certificate authority on their website. Usually, we logon to the site in question, access some sort of management console, paste the text in the proper location and click "submit". The certificate authority will attempt to verify that we own the domain names that will appear on the certificate. This usually involves responding to an email. Once approved, we receive an email with a link to the certificate. We click on the link (we will probably have to logon to the website again), and download the certificate.

In fact, we will probably download a file (in my case a .zip file) containing the certificate requested and an intermediate certificate. I extracted these files and placed them in an easily accessible location (at the root of the C: drive for example). The next step is to install these files, first the intermediate certificate (if there is one) and then the certificate that we requested for our organization.


Install the intermediate certificate (if applicable)

First, we create a custom MMC (Microsoft Management Console) and add the "Certificates" snap-in (File | Add or Remove Snap-ins | Certificates (Local Computer)).

Note: the snap-in should manage certificates for "Computer Account".

Next, we open the Certificates (Local Computer) snap-in, navigate to "Intermediate Certification Authorities", Certificates, right-click, select "All Tasks" and then "Import".




At this point, it is essentially a matter of following the prompts, navigating to the location of the certificate and installing it in the Local Computer certificate store. In fact, once the operation is completed, we should see something like the screenshot above. In my case, the two Starfield certificates have been added.

Now we can install (or "import") the certficate requested for our organization.


Import and Enable the Exchange Certificate

This is the cmdlet that imports the Exchange certificate:

[PS] C:\>Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -path "C:\Certs\458c16fd3f3\458c16fd3f3.crt" -Encoding byte -ReadCount 0))

Note: some may notice that this cmdlet is different from the cmdlet used with Exchange 2007. That is indeed the case. The Exchange 2007 cmdlet does not work with Exchange 2010 (an error message will display).


Next, we have to enable the certificate. Since several certificates may be present, in particular the Exchange self-signed certificate, we need to identify the certificate that we recently downloaded. Although we can use the domain name for this, I prefer to use the thumbprint (which is unique. Another certificate - a previous certificate - may have the same domain name).

[PS] C:\>Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                   --------   -------
BAE508AE4F24D9312A64C-----4B3  ......     CN=mail.mitserv.net, OU=Domain Control Validated
372D7D27CD203E7FF514159-----856  IP.WS.     CN=EX13-1

In this case, we have two choices. The correct certificate here is the one ending in 4B3 (yes, I have abbreviated the thumprint). So we copy the thumbprint and paste it in the following command:

[PS] C:\>Get-ExchangeCertificate BAE508AE4F24D9312A64CE-----4B | Enable-ExchangeCertificate -Services IIS,SMTP,POP,IMAP

We will be prompted to confirm the operation and replace whatever certificate is being used. We can type Y and enter, or simply press "Enter" (the default).

Now the Exchange 2010 server is ready to provide access to clients using OWA, Outlook Anywhere, and ActiveSync. It is also ready to provide encrypted TLS connections with other mail servers, preferred or required as the case may be (Hub Transport role).

Note: POP and IMAP do not have to be included if we have no intention of using either. IIS is for client (web) access and SMTP is for mail transfer between (SMTP) servers.


Export the Certificate for Use on other Servers

If we want to use the certificate on another server, on the Exchange 2007 server (which we do), on a second Exchange 2010 server, or perhaps on a server with ISA/TMG, we cannot simply copy the downloaded .crt file to those computers and import it as we did above. If we try, an error message will display, indicating, in summary, that the private key is missing.

Instead, we have to export the certificate using the cmdlet I will present in a moment and then import the certificate on those other servers. We would also want to import the intermediate certificate provided by the external third-party authority (we can use this certificate directly - there is no need to export it first).

There is one prerequisite: when we created the certificate request at the very start (see above), we should have added this line:

-privatekeyExportable:$true

The value must be "true".

Now we export the certificate so we can use it on the Exchange 2007 server or another Exchange 2010 server. Here is the cmdlet that exports the certificate:

[PS] C:\>$file = Get-ExchangeCertificate BAE508AE4F24D9312A64CEDFACA3DBBF0342A4B3 | Export-ExchangeCertificate -BinaryEncoded:$true -Password (Get-Credential).Password

We will be prompted to enter a username and password. In fact, the username is a formality (it will not be verified for the subsequent import) but we must enter a password.



Import the Certificate on the Exchange 2007 server


Now we can copy the certificate to the Exchange 2007 server (remember, we want to use the certificate that includes the legacy.mitserv.net subject alternative name).

We execute this cmdlet to import the certificate...

[PS] C:\>Import-ExchangeCertificate -path "c:\scripts\mitserv.pfx" -Password:(Get-Credential).Password

We enter the password when prompted...

And then enable the certificate for use with IIS (client access) and SMTP (hub transport operations) - and optionally POP and IMAP:

[PS] C:\>Get-ExchangeCertificate -thumbprint BAE508AE4F24D9312A64CE-----4B | Enable-ExchangeCertificate -Services IIS,SMTP,POP,IMAP

Now, at least as far as certificates go, both servers are ready for the migration operations that will take place later.


***

Note: if we want to import the certificate on another Exchange 2010 server, we would use the command below (different from the command used for Exchange 2007 above):

[PS] C:\>Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -path "c:\certs\mitserv.pfx" -Encoding Byte -ReadCount 0)) -Password:(Get-Credential).Password




Saturday, July 12, 2014

Exchange 2010 (SP3) - Migration - Part 1 - Introduction, Prerequisites and Installation

After several posts about an Exchange 2007 to 2013 migration, migrating from 2007 to 2010 may seem like a step backwards. While migrations to 2010 are probably less common, now that Exchange 2013 is available (recently with SP1), they are an option, notably in the Exchange Server Deployment Assistant (online preparation guide).


In fact, I will use this tool as a general guide and will state my migration framework from the start:

  • We have a single Active Directory domain (and thus forest) and a single site.
  • There is no Edge Server.
  • There are some Public Folders but since their use will cease, there is no need to migrate them.

Since much documentation already exists on Exchange 2010 migrations, my posts will only cover the elements existing in my test environment (itself reflecting a production environment with which I have become involved). So, if I do not consider Public Folders, for example, it is not so much to avoid more complex migration scenarios, but rather to concentrate on the aspects I'll really have to manage "in the field".

The exact migration will be from Exchange 2007 SP3 RU13 to Exchange 2010 SP3 RU6.


Preliminary considerations - Active Directory preparation


Active Directory environment

I will only summarize the Active Directory requirements here  (for full details please consult the Exchange Server Deployment Assistant and related links).
  • The Forest Functional Level (or mode) must be at Windows 2003 or above.
  • The Schema Master must run at least Windows 2003 SP2 (standard or enterprise, 32 bit or 64 bit - that does not matter).
  • Domain controllers in general must run at least Windows 2003 SP2.
  • In every site where Exchange will be installed, there must be a global catalog server running at least Windows 2003 SP2.

My test domain controller is a Windows 2008 R2 SP1 server.

My Forest Functional level is Windows 2008 R2.


Administrative rights

The account used for the operations to follow must be a member of the domain, enterprise and schema administrators groups. It is also a member of the Exchange Organization Management group. Note that membership in the domain admins group makes the account a member of the local administrators group on all member servers. After the upgrade (or extension) of the Active Directory schema, we can remove the account from the schema administrators group (membership in it is only useful for this operation).


Exchange server hardware and operating system

Note: the server must become a "domain member" (be added to the domain) before the actions taken below (some features could be added before domain membership but I recommend making it a domain member from the very start).

Once again, consult the Exchange Server Deployment Assistant for the various possible scenarios (single or multi-role servers).

In summary, we need:
  • A 64 bit operating system (Exchange 2010 is 64 bit only) - either Windows 2008 SP2, Windows 2008 R2 or Windows 2012 (SP3 is required for Windows 2012). Standard version is acceptable unless we want to use Database Availability Groups (DAGs). In that case, we must use the Enterprise version of Windows server (the Enterprise version of Exchange is not necessary for a DAG).
  • Windows 7 SP1 for the Exchange Management Tools.
  • Memory requirements vary based on roles. 4 GB is minimal for production. 8 GB is better. Some environments may require more memory.
  • Storage: any current hard drive will have sufficient space. RAID arrays for the OS, log files and databases are preferred for fault tolerance. Larger environments will most likely use SAN storage, far beyond the scope of this post.
  • Client support: Outlook 2007, 2010, 2013, IE 7 to 11 (for OWA premium client).

The above is a simple summary. For a complete (and updated) list of compatible clients, please consult the Exchange Server Supportability Matrix:

Exchange Server Supportability Matrix


Preparation of Active Directory (schema extension)

We need to prepare Active Directory, the schema in particular, for Exchange 2010 SP3. My preferred method is to place the Exchange 2010 SP3  install files (downloaded from Microsoft and extracted) in a folder on the future Exchange server. We then execute a number of setup commands (two, in a single forest/domain scenario). These commands are presented in greater detail below.

Note: make sure that the server is already a member of the domain.

While the procedure usually succeeds without a problem, it is wise to backup the system state of the schema master before. It is also advisable to verify Active Directory health and ensure that replication is functional, since the changes to the schema (and Active Directory in general) will have to replicate to the other domain controllers.

I would run:

  • DCDIAG (various "switches" are possible here - please consult the documentation).
  • REPADMIN /replsum
  • REPADMIN /showrepl

I could even force replication with the repadmin commands or in Active Directory Sites and Services.

Since I am running Windows 2008 R2 (SP1) for my domain controller, I also have the option of using the Active Directory Domain Services Best Practices Analyzer (which can be found in Server Manager - under the ADDS section, click on "Scan this Role" among the options to the right).

Each administrator will have to analyze the results of the tools above on a case by case basis. The mulitude of possible results that could be obtained, and the measures to take, are beyond the scope of this post.

Once we have ensured that the Active Directory environment is healthy, and replication in particular, we can prepare the schema.

***

We could run the setup commands at this point but I know from experience that some Windows features need to be added before - so I'll add them now and avoid some error messages:

PS C:\> Add-WindowsFeature RSAT-ADDS

PS C:\> Add-WindowsFeature NET-Framework

Note: there are other required features that we will install later. The two above are necessary for the schema extension and general preparation of Active Directory for Exchange 2010 SP3.


Next, we navigate to the location of the Exchange setup files and execute the following two commands:


PS C:\Exchange 2010 Project\E2K10SP3> .\setup /ps

PS C:\Exchange 2010 Project\E2K10SP3> .\setup /p


There will be a confirmation prompt (if you want to stop, press any key) and various information displays on screen as the schema upgrade / Active Directory preparation progresses. If all goes well, this message should display after each of the operations:

"The Microsoft Exchange Server setup operation completed successfully."

Some notes:
  • Of course, the location and the name of the folder containing the Exchange setup files will vary.
  • We must execute the commands in Powershell (not the simple command line interface).
  • We must precede the setup command with .\
  • /ps is an abbreviated form of prepareSchema (we can use that as well).
  • /p is an abbreviated form of prepareAD.
  • If we have multiple domains, we will have to run additional commands in each of those domains.


***

It can be useful to compare the schema levels before and after (if the numbers do not change to the proper level, that would indicate a problem). There are in fact several values to verify.

Before the schema upgrade, the "Forest (rangeUpper)" value should be 14625 and the "Forest (objectVersion)" should be 11222.

We can observe these values with ADSIEdit, looking at the following attributes in the following locations:

CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=mynet,DC=lan



CN=MYNET,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mynet,DC=lan


Note: right-click on the folder to view the properties. We can filter the results so only attributes with values are displayed.

After the schema upgrade, the "Forest (rangeUpper)" value should be 14734 and the "Forest (objectVersion)" should be 14322:.






***

Prerequisites: features, hotfixes and "other software"


Features

The features to install depend on the roles of the server. My "multirole" server will have the Client Access, Hub Transport and Mailbox roles installed. Other combinations are possible. For these other combinations, please consult the Exchange Server Deployment Assistant and related links.

There is a script for this - so we do not have to check every single box manually in the "Features" section of Server Manager - or type every single feature if we opt for the command line (Add-WindowsFeature followed by the name of all the necessary features).

This is the script for a server with the Client Access, Hub Transport and Mailbox roles:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Digest-Auth,Web-Dyn-Compression,Web-WMI,Web-Asp-Net,NET-HTTP-Activation,RPC-Over-HTTP-Proxy –Restart

Yes, one can copy and paste that text into the Powershell console.

Note: I opted to execute the "setup" commands for schema and general Active Directory preparation. This required the installation of .NET Framework 3.5.1 and related features. So some features were installed before executing the script.

There is one more small script to run afterwards:

Set-Service NetTcpPortSharing -StartupType Automatic

As you probably can see, this sets the start type of the NetTCPPortSharing service to automatic.



Hotfixes

The number of hotifxes to install depends on the operating system. Windows 2008 R2 with SP1 only requires one of the hotfixes mentioned for Windows 2008 R2 (without SP1) : KB2550886

The file name was: Windows6.1-KB2550886-x64

This is a hotfix for the Cluster Service.



Other software

Office 2010 Filter Pack

In particular, I used a file named "FilterPack64bitv2".

These filters are used on Mailbox and Hub Transport servers (the CAS role does not require them). The Mailbox role uses them for the indexation of email attachments and discovery searches. The transport rules configured on HubTransport servers use the filters to scan attachments. 


***

Once all the prerequisites are installed, we can install Exchange 2010 itself.

We can use either the GUI, clicking "Next" as needed, or the command line. I'll use the second option here.

This command should suffice:

PS C:\E2K10SP3> .\setup.com /r:"c,h,m" /ExternalCASServerDomain:mail.mitserv.net

Note: we have to navigate to the location of the installation files. We can indicate "setup.com" or simply enter "setup". Either will work.

At this point, I installed Rollup 6 for Exchange 2010 SP3 as well as Windows updates in general.

This concludes the preparation for and the installation of Exchange 2010 SP3 (RU6).