KDB Systems

Installing Exchange 2010 Client Access Role

I decided to bite the bul­let and not worry about not being able to install Exchange 2007 after Exchange 2010 is installed. I’ve got good back­ups for my SBS 2003 server so it’s time to start. I’m going to start slow. I’m just installing the Client Access Role today. First I have to pre­pare the server. I went to the Exchange Server Deploy­ment Assis­tant site, answered a few ques­tions then down­loaded a PDF file with basic instruc­tions on how to pro­ceed. I read over the Exchange stuff on Tech­Net once again just to be sure I hadn’t missed any­thing. I found a great site with a very quick guide to installing all the pre­req­ui­sites. Thank you Pow­er­Shell and netometer.com. A quick check once again on the health of Active Direc­tory and I was ready to go. I can’t stress enough that when installing any ver­sion of Exchange you need a healthy Active Direc­tory. Next up was updat­ing the Schema, Active Direc­tory, and the domain. This all appeared to work with­out a hitch. I waited for the changes to repli­cate then ran the Exchange setup and picked the Client Access Role. It installed just fine. I exited the instal­la­tion and checked the instal­la­tion logs, event logs, and fired up the Exchange Man­age­ment Con­sole. Every­thing looked great. One tip I’d like to pass along is don’t install Exchange from the dis­tri­b­u­tion media. Copy the media to a folder on the server you’re installing Exchange on. You can then copy any Exchange Rollups into the Update folder and they’ll get installed dur­ing the Exchange installation.

The next step involves installing a cer­tifi­cate. I haven’t decided if I’m going to use my own cer­tifi­cate or pur­chase one. I’m lean­ing towards the pub­lic cert. In any case I’ve got to get back to work that pays so I’m going to take a break here.

The next morn­ing my daily report from the SBS 2003 server con­tained a sur­prise. There were over 2,000 errors in the Direc­tory Ser­vice event log. The error was:

Event Type: Error
Event Source: NTDS Gen­eral
Event Cat­e­gory: DS Schema
Event ID: 1136
Date: 4/6/2010
Time: 10:03:44 AM
User: NT AUTHORITY\ANONYMOUS LOGON
Com­puter: SBS-SERVER
Descrip­tion: Active Direc­tory failed to cre­ate an index for the fol­low­ing attribute.
Attribute iden­ti­fier: 2515870862
Attribute name: msEx­chOb­jec­tID
A schema cache update will occur 5 min­utes after the log­ging of this event and will attempt to cre­ate an index for the attribute.
Addi­tional Data
Error value: –1403 JET_errIndexDuplicate, Index is already defined

There were sev­eral AD attrib­utes with this error every five min­utes. A quick Google/Bing found the prob­lem had to do with the regional set­tings. Both servers were set to the Canada region, Cana­dian Eng­lish, and a US key­board. That’s pretty much how I always set up Win­dows. Appar­ently this com­bi­na­tion, and many oth­ers, can cause prob­lems with AD updates. I reset every­thing to US, rebooted and the errors con­tin­ued. Fur­ther search­ing found a needed reg­istry change. I found it on the Microsoft sup­port forums here. The value for US Eng­lish is 0x409 Hex by the way. It took a while to find that as well. After another reboot all the errors stopped. I’m sure I could have fig­ured out how to use Cana­dian Eng­lish but I don’t really care. Set­ting every­thing in the domain to US regional set­tings actu­ally makes many things work bet­ter. Lots of appli­ca­tions just assume US set­tings. Date sorts and dis­plays are often borked up if you use any­thing other than US set­tings so I’m just going to live with Win­dows think­ing I’m in the US J

SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 1)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 2)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 3)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 4)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 5) Com­ing soon

Prepar­ing to move DHCP

As part of the project I have to move the DHCP server from the SBS server to a new server. With Win­dows Server 2008 R2 Enter­prise you get what is called one plus four licens­ing. You can install it on phys­i­cal hard­ware. That’s the one license. If this instal­la­tion is only used as a Hyper-V par­ent you can then install four child par­ti­tions with the same license. So far I’ve used two of these licenses, one for the domain con­troller and one for the future Exchange server. I want to run a Ter­mi­nal Server for the third license. This leaves me with one spare license. I plan to exper­i­ment with Direct Access so I’ll prob­a­bly need the last license for that. Long story short, DHCP would have to go on one of the exist­ing servers. I decided to put it on the domain con­troller. Dur­ing the changeover I’ll be run­ning DHCP on the SBS server and the new domain con­troller. The rea­son for this is one or the other may be down for a while when mak­ing changes. This isn’t nor­mally a big deal as long as none of the exist­ing leases expire or no new com­put­ers get con­nected to the net­work. My prob­lem is I have many dif­fer­ent com­put­ers com­ing and going. I may have cus­tomer com­put­ers I’m work­ing on that would need a new lease. This means two DHCP servers. I installed The DHCP server role on the new domain con­troller, con­fig­ured both the exist­ing DHCP on the SBS server and the new DHCP with the same scope but dif­fer­ent exclu­sions so they wouldn’t be try­ing to give out the same addresses. Once fin­ished I autho­rised the new DHCP server in Active Direc­tory and logged off. The next morn­ing there was a sur­prise wait­ing for me in the daily SBS report. One ser­vice was not run­ning. I logged on to the SBS server and saw that DHCP was not run­ning. I’d for­got­ten one of SBS’s quirks. If another DHCP server is run­ning it will shut down its own DHCP server. A quick Bing/Google search found the reg­istry change and all was well with DHCP run­ning on both servers. One more check­point done on the migra­tion from SBS 2003 to Server 2008 R2 and Exchange 2010.

SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 1)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 2)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 3)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 4)

Prepar­ing a server for Exchange 2010

The Server 2008 R2 domain con­troller has been run­ning for a cou­ple of days. Active Direc­tory repli­ca­tion is work­ing. DNS is installed and work­ing. As a test I went into sev­eral mmc con­soles on the SBS 2003 server and made some changes to Active Direc­tory. The changes repli­cated to the 2008 R2 DC. I did the same thing on the 2008 R2 DC. I made some changes in DNS on both servers as well. All was good. As a bonus I found some orphans in both AD and DNS from when I was test­ing IPv6. I took this as an oppor­tu­nity to clean up AD and DNS. I don’t know if any of these orphan entries would have hin­dered the Exchange migra­tion but it’s always best to have AD as clean as pos­si­ble in any case. Now that AD was ready it’s time to bring up a Server 2008 R2 vir­tual machine to run Exchange 2010 on. The lat­est white paper for 2008 R2 Hyper-V claims there is very lit­tle dif­fer­ence in per­for­mance between dynamic and sta­tic vir­tual disks with Hyper-V 2008 R2 so I decided to test this and installed Server 2008 R2 Enter­prise into a vir­tual machine with 2 vir­tual CPUs, 4.5GB RAM, and a 127GB dynamic vir­tual IDE disk. The RAM may be a lit­tle light. The min­i­mum for Exchange 2010 is 4GB. I made it 4.5 to be a lit­tle above. If that causes per­for­mance prob­lems it’s easy to change later. The same applies to the num­ber of CPUs. If the dynamic disk is a prob­lem I can move the Exchange data­base to a dif­fer­ent disk. I’ll prob­a­bly end up doing that any­way as it’s not the best prac­tice to locate the Exchange data­base, logs, etc. on the same drive as the OS. I installed Server 2008 R2 in the vir­tual machine then down­loaded and installed all the Win­dows updates. Microsoft has some great tools to help with installing Exchange 2010. The first place I vis­ited was the Exchange Server Deploy­ment Assis­tant. This is a great tool that will walk you through many dif­fer­ent Exchange deploy­ment sce­nar­ios. I picked Upgrade from Exchange 2003, answered a few ques­tions on the next screen, and got a step by step check­list of what needed to be done. It’s a great tool. One of the first steps is to make sure you have all the require­ments in place to Install Exchange 2010. Another great tool is the Exchange Pre-Deployment Ana­lyzer. You need to down­load and install this tool. I installed it on the server I’m going to be run­ning Exchange 2010 on. When you run it you have to spec­ify a domain con­troller. I tried it with both domain con­trollers and got the same results. Dif­fer­ent results here would be a sign that some­thing was dras­ti­cally wrong with AD. The report said I had to change the exist­ing Exchange 2003 server to Native Mode and make a cou­ple of reg­istry changes on the server that was run­ning Exchange. I did this, re-ran the scan, and was left with one warn­ing. The warn­ing was that dur­ing the Exchange 2010 instal­la­tion the schema will be updated such that I would no longer be able to install an Exchange 2007 server in the domain. If I want the abil­ity to do this I’d have to install an Exchange 2007 server before installing an Exchange 2010 server. That would be a lot of extra work. This made me pause. I’m not plan­ning on installing any Exchange 2007 servers once the migra­tion is com­plete. If some­thing goes wrong how­ever I had it in the back of my head that I could always just migrate from SBS 2003 to SBS 2008 which includes Exchange 2007. If the schema change when installing 2010 pre­cludes this I’ll have to re-think my upgrade path. I planned to halt the migra­tion here for now any­way. Before I restart I’ll have to do some inves­ti­gat­ing of this issue. I can obvi­ously restore my SBS 2003 server to the state before the schema is changed but if the migra­tion takes a long time this would mess up the restore process. I’d have to restore the SBS 2003 server then restore the lat­est Exchange 2003 data­base. It’s not really that big of a deal but as I was going to pause here any­way I’ll spend some time think­ing about this. Watch for the third instal­ment of this series once I pon­der for a while.

SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 1)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 2)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part 3)
SBS 2003 to Win­dows Server 2008 R2 and Exchange 2010 Migra­tion (Part4)