Renaming a single-label domain to a FQDN

Long ago — eons, perhaps — before I had anything to do with the Windows environment here, someone created the AD domain in my company as a single-label domain (e.g. instead of “example.com” our domain is just “example”). Over the years this has led to lots of “fun” on the part of Windows admins who’ve worked here as the implications of this choice became more apparent.

Since I inherited this system about a year ago, I haven’t really bumped up against any problems stemming from the single-label domain issue… until now. I recently attempted to add a new Windows 2008r2 file server to our DFS replication group/namespace. This totally failed for some mysterious reason. Well, I shouldn’t say “totally” failed, as I was able to add it to the DFS replication group, but unable to add it to the DFS namespace. In my attempt to debug the namespace issue, I deleted the namespace and attempted to recreate it, but just kept getting this error: The namespace cannot be queried. The specified domain either does not exist or could not be contacted.. I couldn’t do anything with the namespace – even clicking on it in the DFS Management console brought up an error. After some searching I found that this was likely due to having a single-label domain. I wasn’t sure why the error was happening even on Windows 2003 machines though, maybe joining a 2008r2 box to the domain made some schema changes? I tried a few suggestions like editing the hosts file but nothing seemed to resolve this.

Fortunately, we didn’t really need DFS namespaces and were able to just direct everybody to the fileserver via its DNS name, though as you can imagine this was clumsy. However, since this has been a problem since time immemorial, I figured it was time to see if it was fixable. After some quick searching, I found RENDOM. However, after even more searching I discovered this TechNet article which says:

The domain rename operation is not supported in Microsoft Exchange Server 2007 or Exchange Server 2010. DNS domain rename is supported in Exchange Server 2003. However, renaming of the NetBIOS domain name is not supported in any version of Exchange Server. Other non-Microsoft applications might also not support domain rename.

Well. We’re running Exchange 2010. So now what? I guess we’re going to have to create a second domain and migrate over to it. We’d already discussed this as a likely way of implementing the rename anyway, since it didn’t seem like “RENDOM” had any rollback procedure – it either just works (hahaha) or semi-works and semi-fails, leaving a wake of destruction throughout AD. Building a second domain seems like a lot of work, but at least we can move users over one at a time, and we get the side benefit of starting fresh, outgrowing the 5+ years of crud that’s accumulated in our AD.

Guess we’ll see what happens. Neither option seems like much fun. I guess the alternative is do nothing, but Microsoft clearly doesn’t think very highly of single-label domains, and anyone who asks about them gets looked at funny. At least it gives us something to do!

Autodiscover mysteriously stopped working (Exchange 2010)

I had Autodiscover working for months but recently it just stopped. I’m not sure why, but it may be related to removing the last Exchange 2003 servers from service recently. Maybe some setting got wiped from AD when I uninstalled Exchange 2003 (as per the procedure Microsoft gives). Basically what was happening was that the email address field was being autopopulated by the user’s UPN rather than their email address. Since we have a single label domain, the UPN isn’t a valid email address, and autodiscovery fails.

Anyway, I ran Get-AutodiscoverVirtualDirectory and it looks like the autodiscover URL isn’t set. Pretty sure I set this at some point.

[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory -server exch2010fe1  | fl InternalUrl,ExternalUrl

InternalUrl :
ExternalUrl :

[PS] C:\Windows\system32>

I just piped this to Set-AutodiscoverVirtualDirectory to correct the problem:

[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory -server exch2010fe1  | Set-AutodiscoverVirtualDirectory -ExternalUrl 'https://webmail.example.com/Autodiscover/Autodiscover.xml' -InternalUrl 'https://webmail.example.com/Autodiscover/Autodiscover.xml'
[PS] C:\Windows\system32>Get-AutodiscoverVirtualDirectory -server exch2010fe1  | fl InternalUrl,ExternalUrl


InternalUrl : https://webmail.example.com/Autodiscover/Autodiscover.xml
ExternalUrl : https://webmail.example.com/Autodiscover/Autodiscover.xml


[PS] C:\Windows\system32>

After resetting the InternalURL and ExternalURL, autodiscover works again (we have SRV records that tell Outlook to look at webmail.example.com for the Autodiscover service).

Hooray!

Exchange 2010 Post-Upgrade weirdness: can't edit Mail Non-Universal Group or Security Group

Now that everyone’s been moved to Exchange 2010 we’ve started using the 2010 Exchange Managment Console/Shell exclusively which has revealed some weirdness. First, we created a new group in AD using an old script (which used LDAP) and created a Mail-enabled Global Security group. We put people in the group, and everything seemed to be working fine until it was discovered that users in the group couldn’t see the group in the Global Address List. Users not in the group had no problem seeing the group. Additionally, users in the group couldn’t see users added directly in 2010. This only appeared to affect the GAL; the users were able to send/receive email fine with the full SMTP addresses.

Continue reading “Exchange 2010 Post-Upgrade weirdness: can't edit Mail Non-Universal Group or Security Group”

Exchange 2010 Post-Upgrade weirdness: can’t edit Mail Non-Universal Group or Security Group

Now that everyone’s been moved to Exchange 2010 we’ve started using the 2010 Exchange Managment Console/Shell exclusively which has revealed some weirdness. First, we created a new group in AD using an old script (which used LDAP) and created a Mail-enabled Global Security group. We put people in the group, and everything seemed to be working fine until it was discovered that users in the group couldn’t see the group in the Global Address List. Users not in the group had no problem seeing the group. Additionally, users in the group couldn’t see users added directly in 2010. This only appeared to affect the GAL; the users were able to send/receive email fine with the full SMTP addresses.

Continue reading “Exchange 2010 Post-Upgrade weirdness: can’t edit Mail Non-Universal Group or Security Group”

Changing all Exchange mailboxes to use database defaults for quota limits with PowerShell

Here’s an example of why I’ve come to love PowerShell. Under Exchange 2003, we set users’ mailbox quota limits per-user, since we initially set them ridiculously high (around 20 GB). The reason we did that was that prior to this year we actually didn’t have any quotas on user mailboxes and the average mailbox was about 9 GB. In preparation for moving Exchange to the datacenter (over our measly 5Mbps upload line) we introduced quotas and over the course of about 2 months gradually lowered the limits as people whittled away their old email until they were under the quota we had established (about 2.25 GB for the no-send limit — I forgot the rationale for that number — and 1.75 GB for the warning limit [the no-receive limit was set to about 40GB since I never wanted users to hit that limit]).

I think the quota limits Exchange 2003 would allow you to set through the UI were capped at around 2.0 GB so to set quota limits above this we used ADModify to update the mDBQuota* settings for each user directly in their AD entries.

However, now all those users have been moved to Exchange 2010 which let me easily set the quota limits on the Exchange DB to 2000 MB (warning) and 3000 MB (no-send). The problem with this was that all the users were set to override the database setting. How could I quickly set them all to use the database default once again? With PowerShell, this was simple:

First, get the list of all users not using the database defaults:
[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' }

When doing any bulk operation, always verify the list of objects you’re going to be modifying before actually doing the modification. 🙂 The first filter I created didn’t have the RecipientTypeDetails in it and included a DiscoveryMailbox, which I didn’t want to touch. The above command affects only UserMailboxes. If the list looks ok, set them all back to defaults:

[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' } | set-mailbox -UseDatabaseQuotaDefaults $true

And voilà, everyone’s back to using DB defaults (which I increased to 3000MB to celebrate not having to do any more mailbox moves any time soon).

Finally, all users moved from Exchange 2003 to Exchange 2010.

I’ve been working on migrating our Exchange environment from 2003 to 2010 for several months. My first post about this is from April 14th, when I was just trying to virtualize our existing Exchange 2003 system. Once that was complete, I started playing around with Exchange 2010 around June or July, and had most of the users moved over to 2010 by the end of August. The last holdouts were Blackberry users. I couldn’t move their mailboxes because our BES was hosted on our original Exchange 2003 server.

BES is another product that I inherited that I had no experience with. It’s BES 4.1.x and while I wasn’t a fan of the UI it seemed to do its job. However, when I started moving people to Exchange 2010 I learned that BES 4.1 doesn’t support Exchange 2010. So, to cut the (absurdly long) story short, I setup BES Express on a new VM, pointed it at our Exchange 2010 server, tested it out (and it worked), and just last week was able (finally) to move the last few users over to Exchange 2010. BES users had to have their phones wiped to join them to the BES Express server, which was the major sticking point.

I can’t believe it actually took that long to complete, but we managed to move all user mailboxes twice (Ex2003 physical -> Ex2003 VM, then Ex2003 VM -> Ex2010 VM) with no noticeable interruption to users (we did the moves at night). OWA 2010 alone would make it worth the upgrade, but I’m actually loving the Exchange Management Shell too.

Anyway… nice to have it completed.

Converting Exchange 2003 conference rooms to Exchange 2010

I’m wrapping up moving mailboxes to Exchange 2010. The last ones to be moved (except for BlackBerry users… thanks BES) are the conference rooms. So the first step was to move them using the Local Move tool, which was pretty simple. But I don’t want them in 2010 as user mailboxes if they can be designated as “rooms,” which they can. So here’s how I’m doing it:

Identify the mailboxes to be moved

Once you figure out the syntax for the “-Filter” flag to get-mailbox, this is easy

[PS] C:\Windows\system32>get-mailbox -filter { (RecipientTypeDetails -eq "UserMailbox") -and ( DisplayName -like "*conference*") }

Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
Conference Room2          ConferenceRoom2      exch2010be1      unlimited
Production Conference ... productionconf       exch2010be1      unlimited
Conference Room 1         conference1          exch2010be1      unlimited
L&D Conference Room       ldconference         exch2010be1      unlimited
Tech Conference Room      techconference       exch2010be1      unlimited
Client Services Confer... csconference         exch2010be1      unlimited
Suite 202 Conference Room 202conf              exch2010be1      unlimited

Convert them to rooms

As Microsoft says in this story about converting mailboxes to rooms, this can only be done via Exchange Management Shell (not EMC), so just pipe the output from the previous command to Set-Mailbox -Type Room:

[PS] C:\Windows\system32>get-mailbox -filter { (RecipientTypeDetails -eq "UserMailbox") -and ( DisplayName -like "*confe
rence*") } | set-mailbox -type room
[PS] C:\Windows\system32>

Done! Now when you create an appointment in Outlook 2007, in Scheduling Assistant, you can click the “Add Room” button to add a room. Hooray.