KDB Systems

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

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)

Through the Microsoft MVP program I’ve been involved with many different product groups over the past few years. I’ve always thought that the competition for resources between product groups was sometimes counterproductive. Sometimes it gets downright ugly. As I’m just on the periphery it’s been hard to get the big picture and fully form my opinions as to exactly what’s going on. Here’s an article by a former Microsoft employee that paints the big picture quite well.

http://www.nytimes.com/2010/02/04/opinion/04brass.html

My hope is that Microsoft will change. I’ve met some brilliant people during my visits there. Because they are stuck in a silo most of their ideas seem to fall by the wayside or when implemented get changed so much in order to get accepted by the other silos they bear little resemblence to the original idea. I think Microsoft realises this and is struggling to change. Let’s hope it happens. Despite Microsoft’s many detractors I believe they were at one time an innovative leader of the computer industry and did much more good than harm.

Update: Here’s Microsoft’s response.

http://blogs.technet.com/microsoft_blog/archive/2010/02/04/measuring-our-work-by-its-broad-impact.aspx