Published by Kerry Brown on 7th April 2010
Installing Exchange 2010 Client Access Role
I decided to bite the bullet and not worry about not being able to install Exchange 2007 after Exchange 2010 is installed. I’ve got good backups 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 prepare the server. I went to the Exchange Server Deployment Assistant site, answered a few questions then downloaded a PDF file with basic instructions on how to proceed. I read over the Exchange stuff on TechNet once again just to be sure I hadn’t missed anything. I found a great site with a very quick guide to installing all the prerequisites. Thank you PowerShell and netometer.com. A quick check once again on the health of Active Directory and I was ready to go. I can’t stress enough that when installing any version of Exchange you need a healthy Active Directory. Next up was updating the Schema, Active Directory, and the domain. This all appeared to work without a hitch. I waited for the changes to replicate then ran the Exchange setup and picked the Client Access Role. It installed just fine. I exited the installation and checked the installation logs, event logs, and fired up the Exchange Management Console. Everything looked great. One tip I’d like to pass along is don’t install Exchange from the distribution 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 during the Exchange installation.
The next step involves installing a certificate. I haven’t decided if I’m going to use my own certificate or purchase one. I’m leaning towards the public 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 morning my daily report from the SBS 2003 server contained a surprise. There were over 2,000 errors in the Directory Service event log. The error was:
Event Type: Error
Event Source: NTDS General
Event Category: DS Schema
Event ID: 1136
Date: 4/6/2010
Time: 10:03:44 AM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: SBS-SERVER
Description: Active Directory failed to create an index for the following attribute.
Attribute identifier: 2515870862
Attribute name: msExchObjectID
A schema cache update will occur 5 minutes after the logging of this event and will attempt to create an index for the attribute.
Additional Data
Error value: -1403 JET_errIndexDuplicate, Index is already defined
There were several AD attributes with this error every five minutes. A quick Google/Bing found the problem had to do with the regional settings. Both servers were set to the Canada region, Canadian English, and a US keyboard. That’s pretty much how I always set up Windows. Apparently this combination, and many others, can cause problems with AD updates. I reset everything to US, rebooted and the errors continued. Further searching found a needed registry change. I found it on the Microsoft support forums here. The value for US English is 0×409 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 figured out how to use Canadian English but I don’t really care. Setting everything in the domain to US regional settings actually makes many things work better. Lots of applications just assume US settings. Date sorts and displays are often borked up if you use anything other than US settings so I’m just going to live with Windows thinking I’m in the US J
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 1)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 2)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 3)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 4)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 5) Coming soon
Published by Kerry Brown on 1st April 2010
Preparing to move DHCP
As part of the project I have to move the DHCP server from the SBS server to a new server. With Windows Server 2008 R2 Enterprise you get what is called one plus four licensing. You can install it on physical hardware. That’s the one license. If this installation is only used as a Hyper-V parent you can then install four child partitions with the same license. So far I’ve used two of these licenses, one for the domain controller and one for the future Exchange server. I want to run a Terminal Server for the third license. This leaves me with one spare license. I plan to experiment with Direct Access so I’ll probably need the last license for that. Long story short, DHCP would have to go on one of the existing servers. I decided to put it on the domain controller. During the changeover I’ll be running DHCP on the SBS server and the new domain controller. The reason for this is one or the other may be down for a while when making changes. This isn’t normally a big deal as long as none of the existing leases expire or no new computers get connected to the network. My problem is I have many different computers coming and going. I may have customer computers I’m working on that would need a new lease. This means two DHCP servers. I installed The DHCP server role on the new domain controller, configured both the existing DHCP on the SBS server and the new DHCP with the same scope but different exclusions so they wouldn’t be trying to give out the same addresses. Once finished I authorised the new DHCP server in Active Directory and logged off. The next morning there was a surprise waiting for me in the daily SBS report. One service was not running. I logged on to the SBS server and saw that DHCP was not running. I’d forgotten one of SBS’s quirks. If another DHCP server is running it will shut down its own DHCP server. A quick Bing/Google search found the registry change and all was well with DHCP running on both servers. One more checkpoint done on the migration from SBS 2003 to Server 2008 R2 and Exchange 2010.
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 1)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 2)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 3)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 4)
Published by Kerry Brown on 15th March 2010
Preparing a server for Exchange 2010
The Server 2008 R2 domain controller has been running for a couple of days. Active Directory replication is working. DNS is installed and working. As a test I went into several mmc consoles on the SBS 2003 server and made some changes to Active Directory. The changes replicated 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 testing IPv6. I took this as an opportunity to clean up AD and DNS. I don’t know if any of these orphan entries would have hindered the Exchange migration but it’s always best to have AD as clean as possible in any case. Now that AD was ready it’s time to bring up a Server 2008 R2 virtual machine to run Exchange 2010 on. The latest white paper for 2008 R2 Hyper-V claims there is very little difference in performance between dynamic and static virtual disks with Hyper-V 2008 R2 so I decided to test this and installed Server 2008 R2 Enterprise into a virtual machine with 2 virtual CPUs, 4.5GB RAM, and a 127GB dynamic virtual IDE disk. The RAM may be a little light. The minimum for Exchange 2010 is 4GB. I made it 4.5 to be a little above. If that causes performance problems it’s easy to change later. The same applies to the number of CPUs. If the dynamic disk is a problem I can move the Exchange database to a different disk. I’ll probably end up doing that anyway as it’s not the best practice to locate the Exchange database, logs, etc. on the same drive as the OS. I installed Server 2008 R2 in the virtual machine then downloaded and installed all the Windows updates. Microsoft has some great tools to help with installing Exchange 2010. The first place I visited was the Exchange Server Deployment Assistant. This is a great tool that will walk you through many different Exchange deployment scenarios. I picked Upgrade from Exchange 2003, answered a few questions on the next screen, and got a step by step checklist of what needed to be done. It’s a great tool. One of the first steps is to make sure you have all the requirements in place to Install Exchange 2010. Another great tool is the Exchange Pre-Deployment Analyzer. You need to download and install this tool. I installed it on the server I’m going to be running Exchange 2010 on. When you run it you have to specify a domain controller. I tried it with both domain controllers and got the same results. Different results here would be a sign that something was drastically wrong with AD. The report said I had to change the existing Exchange 2003 server to Native Mode and make a couple of registry changes on the server that was running Exchange. I did this, re-ran the scan, and was left with one warning. The warning was that during the Exchange 2010 installation 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 ability 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 planning on installing any Exchange 2007 servers once the migration is complete. If something goes wrong however 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 precludes this I’ll have to re-think my upgrade path. I planned to halt the migration here for now anyway. Before I restart I’ll have to do some investigating of this issue. I can obviously restore my SBS 2003 server to the state before the schema is changed but if the migration takes a long time this would mess up the restore process. I’d have to restore the SBS 2003 server then restore the latest Exchange 2003 database. It’s not really that big of a deal but as I was going to pause here anyway I’ll spend some time thinking about this. Watch for the third instalment of this series once I ponder for a while.
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 1)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 2)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part 3)
SBS 2003 to Windows Server 2008 R2 and Exchange 2010 Migration (Part4)
