Tag: Upgrade/Migration

Posted on

Exchange 2010 Gotcha – #1

As I work through migrations to Exchange Server 2010 with my various clients, I’m developing a list of Exchange 2010 “gotchas”. Not necessarily things that are earth-shattering, but do have the potential to be surprising to administrators.

Gotcha #1 revolves around the fact that an Offline Address Book is no longer automatically specified for a new mailbox database. Surprise!

So, just like most other things that require specific processes in Exchange, you should develop a list of items to be performed when you create a new mailbox database, whether you use the Exchange Management Console or the Exchanage Management Shell. Consider this as a list:

  1. Create the database, specifying an individual folder for the database (e.g., E:\DB-Zippy\Zippy.edb) and an individual folder for the log files (e.g., E:\Logs-Zippy). If you are using the EMC, and you do not want to take the default paths, you will have to type the entire path into the path fields (there is no browse button). As a suggestion, using Windows Explorer, first browse to the path where you want to put the files, and copy them into the clipboard, then you can paste them directly into the fields in EMC (or into the EMS, where you always have to enter the entire path).
  2. Set the Offline Address Book (OAB). If you are using the EMS, you can specify the OAB (e.g., “\Default Offline Address Book”) when you create the database. When using EMC, you’ll have to open the property sheet for the mailbox database, click the Client Settings tab, and select the address book via the Browse… button. You should also take this opportunity to verify that the Public Folder database is a valid public folder database (if you still have public folders in your environment).
  3. Set the Journal Recipient. You cannot specify the Journal Recipient during creation when using either EMC or EMS. With EMC, you’ll have to open the property sheet for the mailbox database, click the Maintenance tab, check the box to select the journal recipient, and browse for the particular user.
  4. Set external permissions. If you are using Cisco Unity or RIM’s BlackBerry Server (Enterprise, Professional, or Enterprise Express), then you’ll need to set additional permissions to allow those software packages to access mailboxes contained in this mailbox database. There is no mechanism for performing this operation using the EMC. For BlackBerry, this is the relevant command, executed from the EMS (assuming that your BlackBerry administrative user is named BESAdmin):

Get-MailboxDatabase | Add-ADPermission -User BESAdmin -AccessRights ExtendedRight -ExtendedRights Receive-As, Send-As, ms-Exch-Store-Admin

Obviously, there are additional parameters that can be set. However, these four meet the needs of all my clients and probably will work for you too!

Watch this blog for more “Exchange 2010 gotchas”.

Until next time…

If there are things you would like to see written about, please let me know.

Follow me on twitter: @EssentialExch

Posted on

Microsoft Exchange Server 2010 Release Candidate

After a wait of almost 24 hours – the download is available.

Yesterday, the Microsoft Exchange team announced the immediate availability of the Exchange Server 2010 Release Candidate with this posting. However…. there was a complication… it wasn’t available!

As of a few minutes ago (1630 EST) the situation was resolved and you can now download the RC here.

A couple of quick notes about this release:

  • This is the Enterprise edition of Exchange Server
  • To use the DAG functionality, you’ll need the Enterprise Edition of Windows Server
  • Windows Server 2008 SP2 and Windows Server 2008 R2 are both supported – but no version of Server 2003 or earlier version of Server 2008
  • You will be able to upgrade to the released version of Exchange Server when it is released, but you CANNOT upgrade from Enterprise RC to Standard RTM
  • You cannot install DAG (which uses Windows Failover Clustering) and NLB on the same server (this is a Windows restriction, not an Exchange restriction)
  • This is an RC – that is, it is feature complete but may still have bugs.

There is a huge amount of additional functionality over Exchange Server 2007 – however, much of it is only available in the Exchange Management Shell. Since this release is feature complete, I don’t expect that to change prior to RTM.

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

msExchTargetBridgeheadServersDN and msExchSourceBridgeheadServersDN Errors with Routing Group Connectors

I’m working with a client this week on migrating them from Exchange Server 2003 to Exchange Server 2007.

Their Exchange 2003 environment is a weird one – a A/A/A/P/P cluster. That’s right – Active/Active/Active/Passive/Passive. Whoever sold them that solution made some serious money! 🙂

I’m moving them to a more standard solution – dual front end servers (CAS + HT) and a CCR backend for the mailboxes. Obviously, we are going to have coexistence for some period of time – there are thousands of mailboxes involved.

One of the standard steps in a co-existence scenario is to create a inter-server-version (InterOp) routing group connector (RGC) which allows the Exchange 2003 environment to communicate (i.e., transfer email) with the Exchange 2007 environment.

Today I finished setting up the CAS+HT servers and the CCR servers and began to set up the InterOp RGC. I used the same syntax I’ve used with dozens of other migrations:

New-RoutingGroupConnector -name Interop-RGC -SourceTransportServers server1, server2, server3 -TargetTransportServers ExchCas1, ExchCas2 -BiDirectional $true -PublicFolderReferralsEnabled $true

And… crap. It bombs.

WTF?!?!?

New-RoutingGroupConnector : Active Directory operation failed on dc3.example.com. This error is not retriable. Additional information: The name reference is invalid.
This may be caused by replication latency between Active Directory domain controllers.
Active directory response: 000020B5: AtrErr: DSID-03152392, #1:
0: 000020B5: DSID-03152392, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 315c30e2 (msExchTargetBridgeheadServersDN)
At line:1 char:26
+ new-routinggroupconnector <<<< -domaincontroller dc3.example.com -identity "Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\InterOp-RGC" -sourcetransportservers server1, server2, server3 -targettransportservers ExchCas1, ExchCas2 -BiDirectional $true -PublicFolderReferralsEnabled $true

Well, it has nothing whatsoever to do with “replication latency between Active Directory domain controllers”. I spent far too long heading down that path before I started googling around to see what else might be on the “Interwebs” about this issue.

It turns out that Exchange 2003 assigns indexes to each SMTP Virtual Server on a computer. The New-RoutingGroupConnector command will only connect to SMTP Virtual Servers that have a index value of 1. Is this a bug? Absolutely. Has it been reported? Absolutely. Has it been fixed? Absolutely not. Note that the same error can occur with the attribute msExchangeSourceBridgeheadServersDN – depends on how you construct the cmdlet.

As of the Exchange 2010 beta, this issue still appears.

In a A/A/A/P/P cluster, the indexes for the SMTP Virtual Servers go 1, 2, 3. This means that you can only specify a single SMTP Virtual Server in the New-RoutingGroupConnector cmdlet, and you can only specify the SMTP Virtual Server for the Exchange Server that has the index of 1. This ALSO means that, for the InterOp-RGC to work, that the Exchange 2003 server with the index of 1 must be the routing group master!

Finding those things out cost me several hours of my life. I hope this blog post helps you avoid the same timesink I had!

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

Named Properties, What Lies Ahead…

Microsoft is preparing to make a potentially breaking change that deals with how Exchange Server 2007 handles named properties. This change is scheduled to be a part of Service Pack 2 and of Exchange Server 2010 at RTM.

This change involves the promotion (i.e., the visibility to non-MAPI clients) of X-* headers in incoming e-mail messages. This can potentially affect the operation of e-mail clients that depend on POP-3 and IMAP (and even Outlook, if you are using rules that look at headers).

Unlike certain earlier versions of Exchange, Exchange 2007 and above do not have a STM file – this means that incoming Internet e-mail is ALWAYS translated to MAPI format and that all headers are not necessarily retained – especially if they are X-* headers. This can cause a fidelity issue (i.e., you can’t reproduce EXACTLY what you received). For probably 99.999% of customers – this isn’t an issue. At least, that’s the opinion.

So…. Microsoft is looking for input and they’ve asked for Exchange MVPs to help get the word out.

To express your opinion, see Named Properties, Round 2: What lies Ahead.

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

Named Properties, What Lies Ahead…

Microsoft is preparing to make a potentially breaking change that deals with how Exchange Server 2007 handles named properties. This change is scheduled to be a part of Service Pack 2 and of Exchange Server 2010 at RTM.

This change involves the promotion (i.e., the visibility to non-MAPI clients) of X-* headers in incoming e-mail messages. This can potentially affect the operation of e-mail clients that depend on POP-3 and IMAP (and even Outlook, if you are using rules that look at headers).

Unlike certain earlier versions of Exchange, Exchange 2007 and above do not have a STM file – this means that incoming Internet e-mail is ALWAYS translated to MAPI format and that all headers are not necessarily retained – especially if they are X-* headers. This can cause a fidelity issue (i.e., you can’t reproduce EXACTLY what you received). For probably 99.999% of customers – this isn’t an issue. At least, that’s the opinion.

So…. Microsoft is looking for input and they’ve asked for Exchange MVPs to help get the word out.

To express your opinion, see Named Properties, Round 2: What lies Ahead.

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

Removing the Last Exchange 2003 Server…

Microsoft has lots of guidance about removing the last Exchange 2003 server from an administrative group (see KB 822931) and I definitely recommend you give that a read. They also have a technet article about removing the last Exchange 2003 server from your organization (after you’ve upgraded to Exchange 2007, of course). You should give that a read too.

But if you do these things lots of times (and if you are a consultant, you probably do – or if you play in your Exchange lab a lot, you probably do too); you just need a quick list of reminders. Here is the list I take onsite with me, when I’m removing an Exchange 2003 server:

Verify that all mailbox moves are complete (either within the console or “get-mailbox -server “).

Verify that all public folder moves are complete (“get-publicfolderstatistics -server “). Note: if they aren’t this can be tough. Check the scripts in $ExScripts like MoveAllReplicas and RemoveReplicaFromPFRecursive.

If you do NOT have an Edge server, verify that the Default receive connector allows Anonymous connections.

If you DO have an Edge server, verify that Edge synchronization has occurred and is operational (“test-edgesynchronization”).

Move all Offline Address Book generation servers to servers that will continue to exist

Move the “Default Public Store” on all Exchange 2003 Mailbox Stores to point to a Exchange 2007 PF

Delete the Public Folder databases from the Exchange 2003 server (note: this is not a required step, but if you can’t do this, then de-install of Exchange will fail – so this is a good place to go ahead and figure that out).

Delete both sides of Interop RGCs (and verify that they are the only RGCs still present: “get-routinggroupconnector”)

Delete SMTP connectors from ESM on the Exchange 2003 server (you can do this from the EMC on Exchange 2007 later, but you’ll get a version warning)

Evaluate Recipient Policies and delete all unused RPs from ESM on the Exchange 2003 server

Verify status of all recipient policies (ensure that Mailbox Manager boxes are unchecked)

Note: you may want to record Mailbox Manager settings to recreate MRM policies on Exchange 2007 to replace the MM policies

Relocate the PF heirarchy (in Exchange 2003 ESM, right-click the Exchange 2007 Administrative Group, select Next -> PF Container, drag PF object from the Exchange 2003 Administrative Group to the Exchange 2007 Administrative Group)

Delete the Domain Recipient Update Service(s) from ESM on Exchange 2003

Point the Enterprise Recipient Update Server to an Exchange 2007 mailbox server (or delete the RUS from Active Directory using adsiedit or LDP)

Uninstall Exchange

…..

Now, this is one of those postings where I have to say “this works for me”. I bet it’ll work for you too – but I can’t guarantee it!

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

Removing the Last Exchange 2003 Server…

Microsoft has lots of guidance about removing the last Exchange 2003 server from an administrative group (see KB 822931) and I definitely recommend you give that a read. They also have a technet article about removing the last Exchange 2003 server from your organization (after you’ve upgraded to Exchange 2007, of course). You should give that a read too.

But if you do these things lots of times (and if you are a consultant, you probably do – or if you play in your Exchange lab a lot, you probably do too); you just need a quick list of reminders. Here is the list I take onsite with me, when I’m removing an Exchange 2003 server:

Verify that all mailbox moves are complete (either within the console or “get-mailbox -server “).

Verify that all public folder moves are complete (“get-publicfolderstatistics -server “). Note: if they aren’t this can be tough. Check the scripts in $ExScripts like MoveAllReplicas and RemoveReplicaFromPFRecursive.

If you do NOT have an Edge server, verify that the Default receive connector allows Anonymous connections.

If you DO have an Edge server, verify that Edge synchronization has occurred and is operational (“test-edgesynchronization”).

Move all Offline Address Book generation servers to servers that will continue to exist

Move the “Default Public Store” on all Exchange 2003 Mailbox Stores to point to a Exchange 2007 PF

Delete the Public Folder databases from the Exchange 2003 server (note: this is not a required step, but if you can’t do this, then de-install of Exchange will fail – so this is a good place to go ahead and figure that out).

Delete both sides of Interop RGCs (and verify that they are the only RGCs still present: “get-routinggroupconnector”)

Delete SMTP connectors from ESM on the Exchange 2003 server (you can do this from the EMC on Exchange 2007 later, but you’ll get a version warning)

Evaluate Recipient Policies and delete all unused RPs from ESM on the Exchange 2003 server

Verify status of all recipient policies (ensure that Mailbox Manager boxes are unchecked)

Note: you may want to record Mailbox Manager settings to recreate MRM policies on Exchange 2007 to replace the MM policies

Relocate the PF heirarchy (in Exchange 2003 ESM, right-click the Exchange 2007 Administrative Group, select Next -> PF Container, drag PF object from the Exchange 2003 Administrative Group to the Exchange 2007 Administrative Group)

Delete the Domain Recipient Update Service(s) from ESM on Exchange 2003

Point the Enterprise Recipient Update Server to an Exchange 2007 mailbox server (or delete the RUS from Active Directory using adsiedit or LDP)

Uninstall Exchange

…..

Now, this is one of those postings where I have to say “this works for me”. I bet it’ll work for you too – but I can’t guarantee it!

Until next time…

If there are things you would like to see written about, please let me know!

Follow me on twitter: @EssentialExch

Posted on

SBS 2003 Hardware Upgrade

In May of 2008, I wrote the article SBS 2003 Hardware Migration/Upgrade. Since then, I’ve been asked many times about my process for doing a SBS 2003 hardware upgrade. In general, I just have to say “I follow the steps”.

As I recommended in my original article, if the Microsoft white paper isn’t detailed enough for you, I recommend SBS MVP Jeff Middleton’s SBS Migration Tools.

However, this weekend I had the opportunity to upgrade the hardware for another client of mine, and I wrote down each step as I did it. This list of steps may encourage you to NOT do this. 🙂 There are many opportunities for error. This is a simple list of steps – if you don’t know what the shorthand means – you probably shouldn’t be doing it! 😛 Some of these one-line steps can consume quite a bit of time (e.g., “move wss” – the process is an entire white paper all on its own).

I execute this process in three phases. Phase I is basically “install the software on the new hardware.” Phase II is “configure the software and prepare for migration.” Phase III is “complete the migration.”

Phase I

-1] basic SBS 2003 RTM install
0] Join to AD domain
1] Dcpromo
2] Install DNS and DHCP
3] Change to AD integrated DNS
4] Update NIC(s)
5] move fsmo roles
6] update setup.sdb per http://theessentialexchange.com/blogs/michael/archive/2008/05/18/sbs-2003-hardware-migration-upgrade.aspx
7] Complete the SBS 2003 install
8] install Server 2003 sp1 (WindowsServer2003-KB889101-SP1-x86-ENU.exe)
9] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
10] install WSS 2.0 sp1 (WSS2003SP1-kb841876-fullfile-enu.exe)
11] install Exchange 2003 sp1 (E3SP1ENG.exe)
12] install Windows XP sp2 for client deployment (SBS2003-KB891193-X86-ENU.EXE)
13] install SBS 2003 sp1 (SBS2003-KB885918-SP1-X86-ENU.EXE)
14] install Server 2003 sp2 (WindowsServer2003-KB914961-SP2-x86-ENU.exe)
15] install Exchange 2003 sp2 (E3SP2ENG.EXE)
16] Install kb 943494 (WindowsServer2003-KB943494-v4-x86-ENU.exe)
17] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
18] install Resource Kit Tools (rktools.exe)
19] install Server Support Tools (suptools.msi)
20] install kb 943545 (WindowsServer2003-KB943545-x86-ENU.exe)
21] install Windows-Update/Microsoft-Update patches
22] install OpenManage/Server management tools
23] install FileserverTweaks.reg
24] move fsmo back (only domain fsmo, leave forest alone)

Phase II

1] configure remote access (ie, vpn)
2] activate server
3] add client licenses
4] configure SBS monitoring
5] configure exchange server
 Copy Database Size limit – http://technet.microsoft.com/en-us/library/aa998066.aspx
Verify server property configurations
 Change Offline Address List server for all Offline Address Lists
 Update Recipient Update Service Config
 Copy SMTP Connector / Default SMTP Virtual Server
 Replicate public folders
6] install AV Server
7] install AV Client
8] move ssl certs
9] verify RPC/HTTPs config
10] set up new backup
11] move printers
12] move shares
13] initial file copy

On old server:
1] Install kb 943494 (WindowsServer2003-KB943494-v4-x86-ENU.exe)
2] Install kb 930045 (WindowsServer2003-KB930045-v5-x86-ENU.exe)
3] install kb 943545 (WindowsServer2003-KB943545-x86-ENU.exe)

Phase III

1] move fsmo
2] move mailboxes
3] move DHCP
4] move a/v clients
5] move WSS/SharePoint
6] move websites
7] move wsus
8] check/move Scheduled Tasks
9] move files
10] cut-overUntil next time…

As always, if there are items you would like me to talk about, please drop me a line and let me know!

Follow me on twitter: @EssentialExch