AYUB KHAN

Microsoft Infrastructure & Security Consultant ITIL,MCITP,MCTS,MCSE,CCNA,CCNP,CWNA,CA, NCMA.NCMP,NCVA,NCSA,NCMM. Working as a system consultant specialized in AD,Exchange,Forefront Technolgies,I’d like to share some of my experience and daily operations. I’ll be talking about Active Directory 2008,2012 Exchange2007,2010 Virtualization,Forefront Security Suite of Microsoft Technologies, System center 2012 Family, Pushmail, CA Products Hopefully I’ll be able to cover much more

Tuesday, May 19, 2009

Step By Step Guide for Installing Exchange Server 2010 On Windows server 2008

Install the Windows Vista operating system prerequisites for Exchange Management Tools

To install the Windows Server 2008 operating system prerequisites for Client Access servers

1. Install the Active Directory remote management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
2. Install Microsoft .NET Framework 3.5.
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the necessary Internet Information Services (IIS) prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i NET-HTTP-Activation
ServerManagerCmd -I RPC-over-HTTP-proxy

To install the Windows Server 2008 operating system prerequisites for Edge Transport servers

To install the Windows Server 2008 operating system prerequisites for Hub Transport servers

1. Install Microsoft .NET Framework 3.5.
2. Install the Active Directory remote management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the necessary Internet Information Services (IIS) prerequisites:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth

To install the Windows Server 2008 operating system prerequisites for Mailbox servers

1. Install Microsoft .NET Framework 3.5..
2. Install the Active Directory management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the 2007 Office System Converter: Microsoft Filter Pack.
8. Install the necessary IIS prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
9. If the Mailbox server will be clustered, you must also install the Failover Clustering feature by running the following command:
Copy Code
ServerManagerCmd -i Failover-Clustering

To install the Windows Server 2008 operating system prerequisites for Unified Messaging servers

1. Install Microsoft .NET Framework 3.5.
2. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
3. Install Windows PowerShell V2 CTP3.
4. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
5. Install the extensions for ASP.NET AJAX 1.0.
6. Install the necessary IIS prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
7. Install the Microsoft Windows Media Player audio/video codecs required by the Unified Messaging server by running the following command:
Copy Code
ServerManagerCmd -i Desktop-Experience

To install the latest optional Windows Updates

1. Install multiple Right Management Services (RMS) Client sessions update. See Knowledge Base article 950888 You cannot create multiple RMS Client sessions for one user context on a Windows Vista-based computer.
2. Install performance counter updates. See Knowledge Base article 951116 A memory leak occurs in performance counters that are used to monitor Windows Server 2008-based computers.
3. Install the System Center Operations Manager 2007 console update. See Knowledge Base article 951327 The System Center Operations Manager 2007 console may crash in Windows Server 2008 or in Windows Vista when you open the Health Explorer window.
4. Install the Event Log service update. See Knowledge Base article 952664 The Event Log service may stop responding because of a deadlock on a Windows Server 2008-based computer.
5. Install performance counter values update. See Knowledge Base article 953290 An application may crash when it uses legacy methods to query performance counter values in Windows Vista or in Windows Server 2008.
6. Install Windows PowerShell V2 CTP3.

Installation Steps For Exchange Server 2010

• Insert The DVD of Microsoft Exchange Server 2010 & Click Install Microsft Exchange.

• Click Install Microsoft Exchange Server 2010 & click Next

• Click Next

• In the Language Page, click Next

• Click I accept click to proceed

• Click Next In Error Reporting Page.

• Click Custome Exchange Server Installation Select the Roles you Needed.

• Click next after Entering the Exchange Organization group.

• Click Next.

• Click Next in the page of Readiness Checks.

• Click Install .

• Click Next.

• Click Finish.

Sunday, May 17, 2009

Managing Receive Connectors (Part 4)

Managing Receive Connectors (Part 4)

In this concluding article we will configure more permissions at the Receive Connector level and we will also configure TLS authentication in a receive connector.

In the last article we saw how to manage permissions using the Exchange Management Shell and AdsiEdit.msc. In this article we are going to personalize receive connector permissions in a different way without using the default Permissions groups.

Exchange Server 2007 has a set of predefined Permissions Groups which makes it easier to administer using a single checkbox to define the required permissions. When we have more than one server it might be painful since some organizations need a more restrictive receive connector which can be reached using the procedure outlined in this article. If you do not really need such feature it is strongly recommended to stick with the default Permissions Groups available through the Exchange Management Console or Exchange Management Shell.

Let’s say that we just want an AD Group called Grp_Relay to be allowed to relay in Exchange Server 2007. In order to do that we have to go further than the Receive Connector permission configurations to assign different users than the default list.

Note:
If you use more than one HUB Transport in an NLB scenario for this receive connector, all changes must be made in all NLB nodes to provide the same mode of authentication and permissions.

First of all, we should remove all known groups of the Receive Connector Permissions tab in the Exchange Management Console. To do that we can get the properties of the Internal Relay connector and make sure that there is no group checked on the Permissions tab.

Now, let’s go back to AdsiEdit.msc and right-click on our Internal Relay connector and click on Properties. Click on the Security tab, and add the Grp_Relay group from Active Directory. Make sure that the group has at least the following permissions
(Figure 01):

Submit Messages to Server
Submit Messages to any Recipient
Bypass Anti-Spam
Accept routing Headers

Figure 01

Now, only users that belong to the Grp_Relay group will be able to send messages using the Internal Relay Receive Connector. If any user outside of that group tries to send a message, they will be asked for credential several times; you can validate the error in the Receive Connectors log file. The error will contain the following information:

Inbound authentication failed because the client DOMAIN\username doesn’t have submit permission.

If you have a situation where some servers must relay on Exchange Server without using authentication, you can use the same procedure above to grant permission to Anonymous entry on the Receive Connector Security tab.

Note:
It is not best practice to allow anonymous permission to relay in an Exchange Server box. Make sure that only a set of servers can use this connector using the RemoteIPRanges configuration of the receive connector.

Configuring TLS on a Receive Connector

Okay, now that we have seen how to properly configure the authentication methods and groups in a Receive Connector, we are going to enable TLS in our Receive Connector. First of all, let’s go to the properties of the Internal Relay Receive Connector and then click on the Authentication tab and check the option TLS, as shown in Figure 02.

Figure 02

Now let’s try to connect to this receive connector which has the FQDN defined as relay.apatricio.local (Apatricio.local is my AD FQDN name). Let’s just use the first SMTP verb, EHLO example.org and we can see that the STARTTLS is not being presented which means that even with TLS enabled on the Receive Connector we are not able to use it right now. (Figure 03)

Figure 03

After that connection we can go to the Event Viewer of our Exchange Server and the EventID 12014 (Figure 04) will be there, and the error message gives us a clue about what is happening with our current environment. The simple answer is that there is not a Certificate with the name configured in the FQDN of that Receive Connector.

Figure 04

So, let’s fix it. I will assume that we are using an internal PKI and in order to request a new SMTP certificate using the Exchange Management Shell use the following cmdlet:

New-ExchangeCertificate –GenerateRequest –Path c:\cert.req –SubjectName “cn=relay.apatricio.local” –FriendlyName “Internal Relay Certificate” –PrivateKeyExportable:$True

Now, let’s request the certificate created using the Certification Authority webpage:

1.Logged on Exchange Server open the http:///certsrv, where is your server which hosts the Certification Authority.
2.Click on Request a Certificate link.
3.Click on advanced certificate request.
4.Click on the second link which is Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
5.Open the file C:\cert.req which was created by New-ExchangeCertificate cmdlet and copy the content.
6.Paste the content of that file into the Base-64-encoded certificate request field in the webpage.
7.On the same page, select Web Server in the Certificate Template field and then click the Submit button.
8.On the new page, click on the Download Certificate link and save it in the C:\ root of the Exchange Server.
Let’s import the new certificate, to do that use this cmdlet:

Import-ExchangeCertificate –Path:C:\certnew.cer

Note:
The file name and path is just an example, you have to use the file name and path that you have used in the previous step.

Time to enable the new imported certificate to be used by the SMTP service using the Exchange Management Shell. To enable it we just need to copy the Thumbprint that was shown when we imported the request in the previous step and use this cmdlet:

Enable-ExchangeCertificate –Thumbprint -Services SMTP

You will be prompted to change the default SMTP certificate, just type in N and hit enter.

Let’s test our changes, we will be connecting again in the Internal Relay Receive Connector and we are going to type in the first SMTP verb, ehlo example.org. Did you notice any change? You should, now we have the STARTTLS being offered by Exchange Server. We can also go back to the Exchange Server Event Viewer and we will not see any Transport error like we saw before.

Figure 05

Let’s go back to our Outlook Express to confirm the solution. In the Outlook Express account properties, we have to use an FQDN name in the Outgoing mail (SMTP) field, and this name must be resolved by the client and it also must be same used by the certificate deployed recently (Figure 06).

Figure 06

The second step that must be done is on the Advanced tab where the option This server requires a secure connection (SSL) must be checked, as shown in Figure 07.

Figure 07

Now, let’s send a message using our Outlook Express. We do not need to receive on the Outlook Express client because we did not set up the proper POP3 server, only the SMTP. If the message disappears from the Outbox folder it is a good sign, but let’s validate the log files and we will see that the last message was sent using TLS, as shown in Figure 08.

Figure 08

Conclusion
In this article we have seen how to avoid Event ID 12014 when we configure a new FQDN in a Receive Connector, how to configure a specific group to relay in a specific Receive Connector, and how to configure a certificate and validate the log files to make sure that the configuration is working properly

Managing Receive Connectors (Part 3)

Configuring Receive Connector Logging Settings

We can configure logging per receive connector. In order to enable log filing in a receive connector we should make sure where the log files will be generated. To configure where the log files will be kept before enabling the logging feature at the connector level:
Open the Exchange Management Console.
Expand Server Configuration.
Click on Hub Transport.
Select an available hub transport on the right hand side, and click on Properties.
Click on the Log Settings tab. In the Protocol Log section we can change the path where either Receive Connectors or Send Connectors will be stored by clicking on Browse button. (Figure 01)<>

Now, that we already know where the log files are stored, we can get the properties of any Receive Connector and we have an option called Protocol logging level which by default is defined as None and we are going to change to Verbose (Figure 02). Use Verbose mode only during a troubleshooting scenario, otherwise keep it configured as None

Now, we can send a test message using the SMTP verbs that we saw previously in this series and we will be able to track all communication in the log file, as shown in Figure 03

Configuring Authentication and Permission...
What we have been working on so far is on how to create the receive connector, how to manage some security features and also how to change the listening IPs to make each connector unique. Now we will go over the Authentication methods and Permissions available that can be associated with a Receive Connector.
Receive Connectors use 7 (seven) different types of authentication, which are: No authentication, TLS, Integrated, Basic Authentication, Basic Authentication over TLS, Exchange Server Authentication (Gssapi and Mutual Gssapi) and External Authoritative. These authentication methods are offered to the clients during the SMTP session and after authentication is made the permissions are applied. In order to configure the authentication method that a specific Receive Connector will use, follow these steps:
Open the Exchange Management Console.
Expand Server Configuration.
Click on Hub Transport.
Click on a Receive Connector and click on Properties.
Click the Authentication tab (Figure 04).

Figure 04
We are able to see the authentication method used by a receive connector through a simple telnet session. All available authentication methods are shown after the SMTP verb ehlo. The following table shows the difference on the SMTP answer for each authentication method:
Authentication Method
Response of EHLO
Transport Layer Security (TLS)
250-STARTTLS
Basic Authentication
250-Auth Login
Integrated Windows Authentication
250-Auth NTLM
Externally Secured
250-Auth250 XEXCH50
Okay, we have just seen how to configure the authentication methods that can be applied in a Receive Connector, now we are going to configure an internal relay server, it might be useful where some users/printers/servers must send message using an internal relay server. We are going to create an internal relay connector from scratch and then we will be changing some configurations to demonstrate how we can play with receive connector authentication and permissions to fit your needs.
Let’s create an Internal Receive Connector. This connector will accept a connection on port 25, however the connections will be made only from a set of machines (172.16.171.1 to 172.16.171.20 in this example). We are also going to specify a different FQND; for this internal receive connector we will be using relay.apatricio.local, the following cmdlet can be used to create the connector:
New-ReceiveConnector –Usage:Client –Bindings:0.0.0.0:25 –RemoteIPRanges:172.16.171.1-172.16.171.20 –FQDN:relay.apatricio.local –Server srv-ex01 –ProtocolLoggingLevel:Verbose –Name:”Internal Relay”
Now, that we have just created the Receive Connector, we can go to any machine that belongs to the defined remote IP range and we will receive a prompt of our new receive connector. We can verify the FQND information displayed in the first line (Figure 05).

Figure 05
Okay, now let’s open the Event Viewer in our Exchange Server, and we will see an error number 12014 and MSExchangeTransport Source. This error occurred because we do not have a certificate for the relay.apatricio.local FQDN, yet. We can avoid that message error for now by configuring the internal Receive connector to use Basic Authentication and Integrated Windows Authentication, as shown in Figure 06. We are going to play with TLS and certificates for this connection in the next article.

Figure 06
In the Permission Groups tab, we have 5 different permissions groups which we can associate to a receive connector. These predefined permissions groups are a set of objects that might include users, computers and security groups and they define permissions to well-know SID (Security Identifier), for example (Exchange Users group permission is the Authenticated Users Group in the AD). Using these permissions groups is the recommended solution for the majority of the companies, however we cannot change these permission groups using the Exchange Management Console.
In the Permissions Groups tab, we are going to validate who is allowed to connect to our Receive Connector. In a Client Connector only “Exchange Users” are allowed by default. (Figure 07)

Figure 07
Since we have the proper Authentication method and a permission associated with Exchange Users we are able to test it. To test we can use Outlook Express to create a dummy account using a fake POP3 Server account just to test the SMTP protocol. Make sure that the reply address used in the Outlook Express account belongs to the current list of Accepted Domains in your Exchange organization and also that you are using the proper username and password, and finally configure the account to use authentication using the option “My Server requires authentication”.

Figure 08
Now you can send a message to any e-mail address and the message will be sent. How do we make sure that authentication is working? Easy! During the receive connector creation we configured the logging level to Verbose. Now you understood why I said easy, right? Just look at the log files generated and we will see the authentication process, as shown in Figure 09.

Figure 09
The default configuration works in most scenarios, however sometimes a special set of permissions is required in order to configure a Receive Connector to fit in with company requirements. We are able to configure Receive Connector permissions in two different ways: using the Exchange Management Shell or AdsiEdit.msc.
The first method is using the Exchange Management Shell. To view the current permission of a Receive Connector run this cmdlet:
Get-ReceiveConnector Get-ADPermission
To manage the permissions use Add-ADPermission to add entries in that list and Remove-ADPermissions to remove entries as well.
The second method to set Receive Connector permissions is by using AdsiEdit.msc (by default it comes with Windows Support Tools, the process to install it can be found at Adsiedit Overview).
Using ADSIEdit.msc we can play around with Receive Connector permission:
Open AdsiEdit.msc.
Expand Configuration.
Expand CN=Services.
Expand CN=Microsoft Exchange.
Expand CN=.
Expand CN=Exchange Administrative Group (FYDIBOHF23SPDLT).
Expand CN=.
Expand CN=Protocols.
Expand CN=SMTP Receive Connectors.
On the right hand side, we will see all the Receive Connector of that specific Server (Figure 10).

Figure 10
Right click on a Receive Connector and click on Properties.
Click on the Security tab, and in the list we will see all the Security Identifiers of each permission Group that was associated with the receive connector and all permissions granted as well.
Now we are able to manage the permissions easily using Adsiedit.msc instead of the Exchange Management Shell that requires a little more effort.
Conclusion
In this article we saw how to configure the log settings in a Receive Connector and also how to configure permissions using AdsiEdit and the Exchange Management Shell.

Migration from Exchange 2000/2003 to Exchange Server 2007 (Part 3)

How to replicate Public Folders, move Mailboxes as well as decommission the Exchange 2003 Server.

Replicating Public Folders
When deploying an Exchange 2007 Server with the Mailbox Server role installed into a legacy Exchange organization, Exchange Setup will create one Mailbox database and one Public Folder database on the respective server by default as can be seen in Figure 3.1 below.

Figure 3.1: Exchange 2007 Mailbox and Public Folder Database
The Public Folder database is created so that you can replicate any Public Folder data stored on your legacy Exchange servers to Exchange 2007. Even though you don’t use Public Folders to store data in your environment, there’s one other reason why you might want to keep the Public Folder database mounted on your Exchange 2007 Server. As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service. The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service. If you don’t use Public Folders to store data and only have Outlook 2007 clients deployed in your organization, you can safely remove the Public Folder database, as you don’t have anything to use it for in that case. This also means you can skip the following steps.
Okay let’s get going with setting up a replica for the Public Folders on our Exchange 2003 Server that should be replicated with the new Exchange 2007 Public Folder database. In order to do so we must use either the Exchange 2003 System Manager or the Exchange Management Shell (EMS). For the purpose of this example we’ll use the Exchange 2003 System Manager.
NoteManaging Public Folders using the Exchange Management Console (EMC) is not possible in Exchange 2007 RTM, but will be integrated with Exchange 2007 Service Pack 1.
To add the Exchange 2007 Public Folder database to the replica list on the Exchange 2003 Server, open the Exchange 2003 System Manager, then expand Administrative Groups > First Administrative Group > Folders > Public Folders as shown in Figure 3.2

Figure 3.2: Public Folders in the Exchange 2003 System Manager

Now open the property page of each public folder, then click the Replication tab and add the Exchange 2007 to the replica list as shown in Figure 3.3.

Figure 3.3: Public Folder Replication Tab

NoteExchange 2003 Service Pack 2 introduced a new Public Folder Settings Wizard which makes it a breeze to add servers to replica lists. So if you have a lot of Public Folders in your Public Folder tree, I highly recommend you use this wizard, which you can read more about in a previous article of mine. If you have thousands of Public Folders, you might want to use the Public Folder replica scripts located in the Exchange Scripts folder (which can be found under C:\Program Files\Microsoft\Exchange Server).
Even though you still have legacy Outlook clients (Outlook 2003 and earlier) in your organization, you don’t need to set up a replica for the SCHEDULE+ FREE BUSY or the OFFLINE ADDRESS BOOK system folder. This will be done automatically when deploying an Exchange 2007 Server in a legacy Exchange organization.
When all Public Folders have been replicated to the Exchange 2007 Server, you should remove the old Exchange 2000 or 2003 Server(s) from the replica lists. When any Public folder data has been removed from the respective Public folder instances, you can dismount the old Public Folder stores (E2k3 SP2 won’t let you remove the Public Folder store until the data is gone and it won’t get removed while it’s dismounted). You should verify that your clients are still capable of seeing Public Folder data as well as free/busy information and accessing the offline address book before you delete it though. If this is not the case, I recommend you wait a little longer so that you’re sure the replication has occurred properly.Important:Outlook Web Access (OWA) 2007 doesn’t include a GUI for accessing Public Folders, so in order to access Public Folders using Internet Explorer you must open a separate browser window and type https://FQDN/public. It’s important you’re aware of this missing feature!

Pointing Internet Clients to the Client Access Server
Now would be a good time to point any Internet clients that are OWA, EAS and RPC over HTTP (now called Outlook AnyWhere) in your organization to the Client Access Server running on the Exchange 2007 Server. If you’re using a firewall such as ISA server (which you do, right?), this change is done at your ISA Server firewall. If you for some reason don’t use an ISA Server in your DMZ, but perhaps a Check Point Firewall 1 or a wannabe firewall such as a Cisco PIX, you should do the redirection there. If you don’t have a firewall you should make the change on the external DNS server hosting your Internet domain.
Note:If your ISA Server is configured to pre-authenticate your OWA users, you must change the Authentication method for the OWA virtual directory under Server Configuration > Client Access in the EMC to basic authentication, since it’s configured to use forms-based authentication by default.
So will any users with a mailbox on my Exchange 2000 or 2003 Server still be able to use OWA, Exchange ActiveSync or Outlook AnyWhere (formerly known as RPC over HTTP) to access their mailbox? Yes this will work just fine since the Client Access Server is backward compatible and will redirect the clients to the respective legacy mailboxes on the Exchange 2000 or 2003 server.
Note:When you perform the above changes, your users will no longer be able to access their mailbox using Outlook Mobile Access (OMA), as OMA has been discontinued in Exchange 2007.

Moving Legacy Mailboxes to Exchange 2007
Alright we have reached the part where we’re going to move our legacy mailboxes from Exchange 2000 or 2003 Server to Exchange 2007. Doing so is a straightforward process and can be done using either the Move Mailbox wizard in the Exchange Management Console (EMC) or the Move-Mailbox cmdlet in the Exchange Management Shell (EMS). For the purpose of this article series we’ll use the EMC. So if it’s not already open, launch the EMC, then expand the Recipient Configuration work center and click the Mailbox sub-node. Now highlight all the legacy mailboxes as shown in Figure 3.4, and then click the Move Mailbox task in the Action Pane.

Figure 3.4: Selecting Legacy Mailboxes in the Exchange Management Console

This will launch the Exchange 2007 Move Mailbox wizard, where you need to specify the destination server, storage group and mailbox database. Select the Exchange 2007 Server in the drop down box (Figure 3.5), and then click Next.

Figure 3.5: Specifying the Exchange 2007 Server as the Destination Server

Now specify how you want to manage any corrupted messages found in a mailbox (Figure 3.6), then click Next.

Figure 3.6: Specifying how corrupted messages in mailboxes should be managed

On the Move Schedule screen shown in Figure 3.7, select Immediately (unless you want the mailboxes to be moved automatically at a later time) and click Next.

Figure 3.7: Move Mailbox Scheduling Options

Finally click Move in order to start moving the legacy mailboxes to the Exchange 2007 Server (Figure 3.8).

Figure 3.8: Move Mailboxes Summary Page

As is the case with the Move Mailbox wizard in Exchange 2003, the Exchange 2007 Move Mailbox wizard can move 4 mailboxes at a time, and only one instance of the wizard can run on a server.
When all the mailboxes have been moved to the Exchange 2007 Server click Finish in order to exit the Move Mailbox wizard, and then check that mail flow to/from the Internet to the mailboxes on the Exchange 2007 works as expected.
If you will be running in a co-existence environment for a period of time, it’s important to understand that mailboxes stored on an Exchange 2007 server must not be managed using the Active Directory Users and Computers (ADUC) MMC snap-in, but instead must be managed using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). However Exchange 2003 mailboxes can still be managed using ADUC.
Note:If you want to move the Mailboxes using the Exchange Management Shell (EMS), you do so using the Move-Mailbox cmdlet. Using the Move-Mailbox cmdlet gives you a set of advanced options, among which the most interesting one is the option of specifying the number of mailboxes to be moved at a time (as you read earlier the Move Mailbox wizard is limited to 4).

Redirecting Inbound Mail to the Exchange 2007 Server
When all legacy mailboxes have been moved to the Exchange 2007 Server, we can point SMTP traffic (port 25/TCP) directly to the Exchange 2007 Server, so that inbound messages are routed directly to this server. It’s recommended to deploy an Edge Transport Server in your perimeter network (aka DMZ), and let this server route inbound messages to the Exchange 2007 server on your internal network. Instructions on how to deploy an Edge Transport server is outside the scope of this article series, but I’ll cover that topic in another article in the near future. If you don’t want to deploy an Edge Transport server, you should bear in mind that you need to change the Permission Groups settings on the Default receive connector under the Server Configuration work center node> Hub Transport sub-node in the EMC so Anonymous users are allowed to connect to the Exchange 2007 Server as shown in Figure 3.9, otherwise you won’t be able to receive e-mail messages from other SMTP servers on the Internet.

Figure 3.9: Permission Groups Settings on the Default Receive Connector

In addition you should make sure that any Send Connectors under Organization Configuration > Hub Transport > Send Connector tab are configured so that they can send outbound mail (either using a smart host or DNS MX) properly (Figure 3.10).

Figure 3.10: Send Connector Settings

When the necessary changes have been made, we can delete the routing group connector which was set up to establish mail flow between the Exchange 2003 and 2007 Routing Groups. In order to do so you should expand Administrative Groups > First Administrative Group > Routing Groups > Connectors and right-click on the respective Routing Group Connector then select Delete in the context menu as shown in Figure 3.11.Note:Officialy the correct way of deleting the routing group connectors is to use the Remove-RoutingGroupConnector cmdlet, but since Exchange 2003 version blocking doesn’t block deletes, you can also use the Exchange 2003 System Manager as well.

Figure 3.11: Deleting the Routing Groups Connector

Since the Routing Group connector won’t be deleted in both ends, you also need to delete it under the Exchange Administrative Group (FYDIBOHF23SPDLT) > Exchange Routing Group (DWBGZMFD01QNBJR) > Connectors.

Decommissioning Exchange Legacy Servers
The final step is to decommission the Exchange 2000 or 2003 Server and we can consider the transition done. The Exchange 2003 server should be removed using the Exchange 2003 Setup program, which can be launched via Add or Remove Programs (Figure 3.12).

Figure 3.12: Add or Remove Programs

But before you begin uninstalling the Exchange 2003 Server, we first need to assign the Recipient Update Service (RUS) to our Exchange 2007 Server. Not because RUS should be used (in fact Exchange 2007 no longer uses RUS), but because the Exchange 2003 Setup program won’t let us uninstall Exchange 2003, before RUS has been assigned to another server. In order to assign RUS to the Exchange 2007 Server, open the Exchange 2003 System Manager, then expand the Recipients node and select Recipient Update Services. Now open the property page both for Recipient Update Service (Enterprise Configuration) and Recipient Update Service (domain), then click the Browse button under the Exchange Server text box and specify the Exchange 2007 Server instead, then click OK twice and close the System Manager as shown in Figure 3.13.
NoteIt's important you don't delete the recipient policies in the Exchange 2003 System Manager, since Exchange 2007 uses them when provisioning users.

Figure 3.13: Assigning the Recipient Update Service to the Exchange 2007 Server

Note:Microsoft will release an Exchange 2003 hotfix, which will prevent one from reassigning the RUS to an Exchange 2007 server some time in the future. The reason being, this really is an invalid setting that should be blocked. Instead the recommendation will be to use ADSIedit to remove the enterprise RUS object.
Now we can continue uninstalling the server, so select Microsoft Exchange then click the Change/Remove button.
The Exchange 2000 or 2003 wizard will appear, click Next then select Remove in the Action dropdown box as shown in Figure 3.14. Click Next.NoteIf your organization relies heavily on Public Folders, you might want to leave the Exchange System Management Tools intact, as you can use them to administer Public folders on your Exchange 2007 server. Remember Exchange 2007 doesn't have a UI for Public Folder Management.
Figure 3.14: Exchange 2003 Installation Wizard Component Selection Page
On the Installation Summary page click Next and wait for the Exchange 2003

uninstallation process to complete (Figure 3.15).
NoteIf the Exchange 2000 Setup files aren’t located on an accessible drive, network share, you will be prompted to insert the Exchange 2003 CD media during the uninstallation process.

Figure 3.15: Exchange 2003 Uninstallation Process
When the uninstallation process has completed click Finish to exit the Exchange 2003 Setup wizard (Figure 3.16).

Figure 3.16: Exchange 2003 Successfully Uninstalled

Alright we’re done!
NoteIf the Exchange 2003 uninstallation for some reason fails, it may be necessary to remove the Exchange 2003 Server by deleting the Server object in the Exchange System Manager or even via ADSIEdit if this isn’t possible. But please don't delete the respective legacy (Exchange 2003) Administrative Group, as the user's legacyDNs still points there, even though their mailboxes are being moved in a native organization.
Conclusion
Doing a transition from an Exchange 2000 or 2003 Server to an Exchange 2007 in the same Active Directory Forest is a straightforward process, and since Exchange 2007 co-exists just fine with legacy Exchange servers, you can do the transition at your own pace. Co-existence support is laudable as a transition process typically happens in several phases. This is especially true if you’re going to do a transition from multiple legacy Exchange Servers to multiple Exchange 2007 Servers.I like the fact that the Exchange 2007 Setup wizard knows when Exchange 2007 is deployed in an existing legacy Exchange organization, and in this case prompts you to create a routing group connector so that mail flow is established between the legacy routing group and the Exchange 2007 routing group. It’s also nice to see that Exchange 2007 Setup, in this case, creates a Public Folder database and automatically adds the Exchange 2007 Server to the OFFLINE ADDRESS BOOK and SCHEDULE+ FREE BUSY system folders replica lists, so you only have to concentrate on replicating Public Folders.Finally it’s a real pleasure working with the Exchange 2007 Move Mailbox wizard (or Move-Mailbox cmdlet) in order to move legacy mailboxes to an Exchange 2007 Mailbox Server, but I must admit, support for Public Folder management in the Exchange 2007 Management Console GUI is missed.

Migration from Exchange 2000/2003 to Exchange Server 2007 (Part 2)

Installing Exchange Server 2007

We have reached part 2 in this 3 part article series covering how you transition from an Exchange 2000/2003 to an Exchange 2007 Server deployed in the same Active Directory Forest. For the purpose of this article we will only install one Exchange 2007 Server, and we’ll do so by selecting a typical installation of Exchange 2007. Since a typical installation of Exchange Server 2007 installs the Mailbox, Hub Transport and Client Access Server roles on the respective server, we must make sure the following software and Windows components are installed on the server prior to launching Exchange 2007 Setup.
Required Software
Microsoft .NET Framework Version 2.0 (including this update)
Microsoft Management Console (MMC) 3.0 (bear in mind MMC 3.0 is installed by default when using Windows Server 2003 R2)
Windows PowerShell V1.0 (can be found here or on the Exchange 2007 DVD media)
Required Windows Components
Mailbox Server
Enable network COM+ access
Internet Information Services
World Wide Web Service
When installing the Mailbox Server role, you also need to make sure you install the hotfixes mentioned in MS KB article 904639 and 918980.
Client Access Server
World Wide Web Service
Remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) Proxy Windows networking component (Required only if you are deploying clients that will use the Outlook Anywhere functionality, previously called RPC over HTTP)
ASP.NET v2.0
Hub Transport Server
No additional Windows components are required by the Hub Transport server; however you must make sure that the SMTP and NNTP services are NOT installed.
NoteListing the hardware requirements for Exchange 2007 is outside the scope of this article's series. For information on hardware requirements see this section in the Exchange Server 2007 Online Documentation.
When ready navigate to the network share containing the Exchange 2007 Setup files, or insert the Exchange Server 2007 DVD media, then double-click on Setup.exe. This will bring us to the Exchange 2007 splash screen shown in Figure 2.1. Click Step 4: Install Microsoft Exchange.

Figure 2.1: Exchange 2007 Setup Splash Screen

Setup will copy the necessary files and soon after begin initializing. After initialization completes, you will be taken to the first step in the Installation Wizard, the Introduction page where you should click Next.
You will now be presented with and need to accept the terms of the end-user license agreement (EULA). I know reading the License Agreement is not among the most exciting things in the world, but you should at least spend a couple of minutes skimming through it. When you have done so, select I accept the terms in the license agreement, and then click Next. After clicking Next you will be taken to the Error Reporting page, where you should decide if you want to enable this feature or not. When you have done so click Next.
As you can see in Figure 2.2, now is the time to select the type of installation we want to perform, as we’re going to do a typical installation of Exchange Server 2007, select this option, then click Next.

Figure 2.2: Selecting a Typical Exchange Server Installation

In order to establish mail flow between the Exchange 2000/2003 and the Exchange 2007 routing groups, we now need to create a routing group connector (Figure 2.3). To do so click Browse then select the Exchange 2000 or 2003 bridgehead server to which you want to connect Exchange 2007, then click Next.

Figure 2.3: Specifying an Exchange 2000 or 2003 Routing Group

The Exchange 2007 Setup wizard will now go through a set of prerequisite checks in order to see whether Exchange is ready to be installed. If you have installed all the necessary software, Windows components and hotfixes, it should complete without any warnings or errors. If this is not the case you should review the issue and if possible click the Recommended Action link in order to see an explanation of or a resolution to the warning or error.
When all issues have been resolved click the Install button and let Exchange Setup copy the necessary Exchange files and install and configure each server role.
Note:If you didn’t run any of the setup preparation switches mentioned in part 1 of this 3 part article series, the Exchange 2007 Setup wizard will prepare the Active Directory before it begins installing the respective server roles.
When Setup has completed installing all the Server roles, click Finish (Figure 2.4).

Figure 2.4: Exchange 2007 Setup Completed

Finalizing Deployment
With the Exchange 2007 Server installation in place let’s launch the Exchange Management Console (EMC). Note that the first time the EMC is launched it will show you the Finalize Deployment tab under the Microsoft Exchange node as shown in Figure 2.5. You should examine each of the deployment tasks listed here, and perform the ones that are relevant for your environment.

Figure 2.5: Finalize Deployment Tab in the Exchange Management Console

Since each deployment task is explained in a step by step fashion, I won’t go into details about each of them here.
End-to-End Scenario Tasks
In addition to the Deployment Tasks we just covered, there’s also an End-to-End Scenario tab (Figure 2.6), which provides a list of tasks that are optional for configuring features, but you should at least skim through each of them and see whether any of these tasks are relevant to your Exchange environment.

Figure 2.6: End-to-End Scenario Tab in the Exchange Management Console

Again, since each task under this tab is pretty much self-explanatory, covering each of them is outside the scope of this articles series.
Global Settings
Global Settings that have been configured on an Exchange 2000 or 2003 Server will be transferred to the Exchange 2007 Server automatically, as these settings are stored and read from Active Directory. This means that recipient policies, Internet Message Formats, SMTP connectors and Exchange delegation permissions are applied to user mailboxes stored on Exchange 2007 as well. Figure 2.7 below shows you the Default Policy which was originally created on our Exchange 2003 Server.

Figure 2.7: Default Policy in the Exchange 2007 Management Console
Also note that when the Exchange 2007 Server has been deployed in the legacy Exchange organization, any of the organization-level settings should be managed using Exchange 2007 Management tools (EMC or EMS) during the co-existence period.
That was it for part 2 but you can look forward to part 3, which is the last article in this article series, which will be published in the near future. In part 3 we’ll replicate public folders, move mailboxes as well as a few other things before we finally decommission the Exchange 2003 server. See you then!