iPhone, GoDaddy, and ActiveSync

So, today I did my first implementation of ActiveSync for an iPhone and I'm pleased to say it worked great when using a GoDaddy certificate.

For those of you that are not aware, GoDaddy sells 1-year domain validated certificates for about $30US while competitors often charge $150US or more. The only catch is that occasionally, some (typically older) applications or operating systems do not properly trust the GoDaddy certificates. However, I'm seeing this less and less. All of our recent (last year or two) Windows Mobile devices have been fine with GoDaddy certificates as well.

New Privacy Options at CIRA

CIRA is responsible for managing the .ca domain. To comply with Canadian privacy laws they now offer the option to keep the adminstrative and technical contacts for a domain registration private. This is intended to be used by individuals rather than business domains.

Business can also select the option to keep their information private but should not. For two reasons:

• Domain-based certificate verification cannot be performed. When obtaining certificates for Web servers and such, the cheapest certificates used for SSL are those performed by domain verification. These certificates are approved by sending an e-mail to the administrative contact for a domain. When privacy is selected at CIRA, these providers cannot view the Administrative contact and consequently cannot send the verification request.
• Other contact is also not possible. There may be legitimate reasons why someone would want to contacts you, such as notifying you of misconfiguration in your DNS domain. This is also not easily possible.

It should be noted that Businesses have no right to privacy under Canadian law. The right to privacy applies only to private individuals.

IPv6 and Exchange 2007

Hopefully this post prevents someone from the pain I went through with Exchange 2007 SP1 running on Windows Server 2008. The short version is this: Exchange 2007 SP1 running on Windows Server 2008 requires IPv6 to run properly.

We have a server that we support with Exchange 2007 running on Windows Server 2008. We took over support of this server from another company. Consequently there are always surprises. We try to do most of our service remotely and we had not rebooted the server in the 3 months we had been managing it. After performing some maintenance on it, we did a reboot and all hell broke loose.

Symptoms were:

• Terminal services no longer functional


• Exchange services not starting, specifically the Hub Transport service


• Limited functionality in most MMC snap-ins (Server Manager would open but not show information, services would open and show status but not allow you to change startup configuration of a service)

Basically, the server was hooped. Eventually we edited the registry to stop the Exchange services from starting automatically and we got control of the server back.

The clue to resolving the problem came from the event logs. The day before we had removed a domain controller and all seemed to be working Ok at the time. However, it appears that the Exchange server had been talking to that DC rather than the DC/GC running on the local server (this is a small organization with only two servers).

The error appeared as:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1880). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name Roles Enabled Reachability Synchronized GC capable PDC SACL right Critical Data Netlogon OS Version)
In-site:
dc1.domain.com CDG 1 0 0 1 0 0 0 0 0

Previous to removing the DC2, the application log Event ID 2080 showed this:

Process STORE.EXE (PID=1992). Exchange Active Directory Provider has
discovered the following servers with the following characteristics:
(Server name Roles Enabled Reachability Synchronized GC capable PDC SACL
right Critical Data Netlogon OS Version)
In-site:
dc2.domain.com CDG 1 7 7 1 0 1 1 7 1
dc1.domain.com CDG 1 0 0 1 0 0 0 0 0

After enabling IPv6, everything was function and Event ID 2080 showed this:

Process STORE.EXE (PID=1924). Exchange Active Directory Provider has
discovered the following servers with the following characteristics:
(Server name Roles Enabled Reachability Synchronized GC capable PDC SACL
right Critical Data Netlogon OS Version)
In-site:
dc1.domain.com CDG 1 7 7 1 0 1 1 7 1

The weird part, is that we don't recall ever disabling IPv6. So, our best guess is that the system was up and running just fine with IPv6 enabled. Then at some point, the previous support company disabled IPv6, but there had been no reboots until this time. Then after the reboot things stopped working. It is likely that when an DC/GC is available on another server it continutes to function properly with IPv6 disabled, but I wasn't about to test theories at a client site.

I found MS docs that indicate IPv6 is a requirement when running Exchange 2007 on Windows Server 2008 unless you go through some hoops to completely disable it. Also related to IPv6, with anything less that update rollup 4 for SP1, Outlook Anywhere has problems when IPv6 is enabled.

So, the simple solution is to patch Exchange 2007 with the most recent update rollup and leave IPv6 enabled.

Windows 2008 Downgrade Rights

When you buy Windows Server 2008 as retail, OEM, or volume licensing you automatically have downgrade rights to use a previous version of Windows server such as Windows Server 2003. This is required because a number of applications are still not certified to run on Windows Server 2008.

If you have purchased Windows Server 2008 via volume licensing then the process for downgrading is simple. Contact Microsoft, and they will provide you with a download of the media and a license key to use.

If you have purchased Windows Server 2008 as retail product or OEM then the process is more complex as Microsoft will not provide you with the media or a license key. MS basically indicated that you have the right to downgrade but they do not provide the means. You can perform the downgrade by:

• Obtaining an OEM key and media from any source. The source could be another server you own or another company or your OEM vendor. You do not need to own the OEM key and media used.
• Obtaining a retail key and media from any source. Again, you do not need to own the retail key or media, just obtain and reuse it.
• Note that you are not allowed to use the volume license key of another oganization. Only your own volume license key.

When purchasing servers for this reason alone, I would consider volume licensing over OEM versions of Windows Server. It may be a few dollars more (not much), but you gain flexibility. As well, you should consider that OEM versions are tied to the specific hardware you bought it on and cannot be migrated to new hardware. A new OEM version must be purchased for new hardware.