totalnetsolutions.net

I’ve been fighting K9Mail for weeks now, trying to get it to sync with MailStreet (http://www.mailstreet.com who hosts “exchange.ms”) hosted Exchange. If you’ve already followed the instructions at the K9Mail Wiki with no success, read on.

Thanks to the k9mail wiki on debugging connection issues and the fact that I already had the Android SDK installed, I was able to solve the 2 related errors I was getting. I would either get an “HTTP 404 not found” or an “HTTP 501 Not Implemented” depending on the settings I chose. With no additional settings other than suggested in the Wiki, I’d get a “501 not implemented”. If I tried to set a mailbox path, or a WebDAV path, I’d get the HTTP 404 Not Found.

In the debugging log, I saw that the system was calling “http://mail.$domain.exchange.ms/”$webDAVpath/Inbox – if I set it to a full URL, the full URL was getting appended. When I attempted to hit those same paths in a full browser, I’d always get an HTTP 404. So, digging in my history in Firefox, I found the following (cleaned) path:
http://mail.$domain.exchange.ms/exchange/$emailaddress/
In this case $emailaddress was my Exchange mail address with the “@” stripped out. Appending “Inbox” to the end of this path resulted in a valid load of my OWA inbox.

Plugging then: /exchange/$emailaddress/ into the WebDAV box in K9Mail, and my email immediately loaded up.

Now I have Android syncing my calendars and contacts, and k9mail is handling my massive inbox!

I recently build a Windows Small Business 2003 Server that was a migration from old hardware. Following this guide from Microsoft makes it pretty straightforward. However, there are a few things I noticed, especially this late in Windows 2003′s lifetime.

1. The guide mentions “Join the new server to the domain” as part of the DCPromo process. I like to separate this out as a way of verifying the join goes well, and that the server can get fully patched more easily. There is a 7 day limit to having 2 SBS 2003 servers live on the network at the same time, and it’s enforced by the old server shutting down after 1 hour uptime. However, this limit isn’t enforced untill after you run the second part of the SBS setup (the first part is the OS setup, the 2nd is the Windows mode “double-click to run” setup). This gives you time to patch and prepare the OS prior to that time limit starting.
2. Once the 2nd part of setup has been run, migrate your users immediately.
3. Migrating users includes moving their mapped drives to the new server. The Client Side Caching Tool from Microsoft will make this much easier. I normally do this change as follows:
   1. Create the share on the new server, if you’re not using the default SBS \Users share.
   2. Edit all user’s profiles to point to the new location. I’ll post a script for this later, but all of the ones I have at this time are protected by IP contracts, and therefore non-sharable. I believe there’s at least a stub for this at either Don Jones’ Scripting Answers or Microsoft’s Script Center.
   3. I have yet to see an SBS environment with no laptops. Therefore, you’ll want to move the Client Side Cache for the My Documents of your users.
      1. Copy csccmd.exe to your NetLogon share on your DC (c:\WINDOWS\SYSVOL\sysvol\domain.local\scripts by default)
      2. Find the current path, and new path (\\dc01\Users for current, and \\dc02\Users for new, below)
      3. Make the logon script be: “\\domain.local\netlogon\csccmd.exe /moveshare:\\dc01\Users \\dc02\Users”
      4. When all the laptop users have logged in and run this script, unlink the GPO but keep it around for documentation (knowing how documentation is in most Small Businesses I’ve visited). This will speed up logons for everyone.
4. Now you can finish the Exchange / SharePoint / ISA setup. This will require downtime, but is easy to do, if you’re following the document referenced above.
5. Finish up cleanup of Exchange prior to the 7 day timeout value. you’ll need to replicate all the Public Folders, OAB, and Free/Busy data as documented in the “Migrating to new Hardware” document.
6. Uninstall Exchange on the original server.
   1. Requires “Modify”ing the Small Business Server roll in “Add/Remove” programs. choose to uninstall Exchange.
   2. This cleans up a huge number of items in AD, and makes future migrations simple. Also cleans up potential problems down the road.
7. DCPromo the original DC, so it’s not a DC on the original network. Just run “dcpromo” and remove the server from being a DC.
8. Now you can shut down the old DC and have no issues.

However, if you follow my guide directly, you’ll run into a single issue: https://servername/oma (or Exchange ActiveSync) will fail with an error: Server Error in '/OMA' Application.
Collection was modified; enumeration operation may not execute. You will only see this error if you try to access the site directly from the new SBS2003 server. Remotely, you’ll just get a generic error.

This is caused by .NET Framework 2.0 being installed *prior* to Exchange 2003. If you join the domain with the DCPromo and do patching *after* the fact, this probably won’t come up, because .NET Framework 2.0 won’t install untill after Exchange 2003 is installed. If, however, Exchange 2003 is installed first, you’ll probably get this error.

Good news, it’s a simple fix:
c:
cd\windows\Microsoft.Net\Framework\v1.1.4322\
aspnet_regiis -sn W3SVC/1/ROOT/OMA/
iisreset /restart

It might take 2 minutes to initialize, but OMA and ActiveSync should now work flawlessly.  As is always implied, contact us somehow if you have issues!

As I mentioned in my last clustering post, there are some Exchange problems we’ve been working on over the past few weeks.  One of the simpler problems has a complex answer, so I thought I’d explain a bit.

As any good Exchange administrator knows, Exchange stores its data (for a store) in 2 files, the EDB file, and the STM file.  However, there’s not a really great explanation of the differences between the two files – the best I’ve found so far is at MessagingTalk.org, but they only explain that the STM is MIME formatted, and the EDB is MAPI content. Why, though, and how does it affect the end users? This is what we’ll explore. (more…)

I’ve been very busy with clients over the past 2 weeks, troubleshooting Clustering problems, Exchange issues, and planning a new trust relationship, on top of normal maintenance and design. As I solve each issue, I’ll be posting what I can about them. This week we were able to solve the odd clustering problem…

We’ve seen some issues over the past approximately 2 months, particularly with MS SQL 2000 clusters (1 Exchange 2003 cluster), where the cluster group fails on one node, and the other node (or nodes) fails to pick up the group, leaving the complete cluster group offline. In each of the cases (on both HP and Dell hardware) the first striking piece of evidence in the logs is that all nodes that fail to bring up the cluster report that the Cluster IP Address resource couldn’t be brought online, because of an IP address conflict on the network

Making this issue particularly fun is that most of the information we used to solve the problem, is a lack of information.  In particular, there is absolutely nothing interesting at all in any nodes’ cluster.log file.  You see the disks negotiate from node to node, but nothing that makes the failover look any different than if you had right-clicked the group and chosen “Move Group” from Cluster Administrator.

What starts the problem off is Event ID 1228 from source “ClusNet”, which says that the “ClusNet driver couldn’t communicate with the ClusSvc for 60 seconds, the Cluster service is being terminated.” Most of the time, you might even miss that this event is there, because it causes so many Event Source Tcpip, ID 4199; Source ftdisk, ID 57; and Source ntfs event ID 50 events, that it’s easy to look over 1 little error. Especially when monitoring systems like Microsoft Operations Manager (MOM), or Idera SQLDiagnostics Manager (SQLDiag) or HP Systems Insight Manager (SIM) all report the cluster as having issues 30-60 seconds after the CluNet 1228 event is written (timing which corresponds exactly to the Tcpip 4199 events (IP address conflict) or the ftdisk 57 events (failed to flush transaction data).  So, here’s what happens, based on conversations with Microsoft, training with Microsoft and HP, and a LOT of reading. (more…)

I have been working with a client and Microsoft on a very difficult issue with their Exchange 2003 system.  A few months ago, a particular store started exhibiting Event ID 623 errors from source ESE – the Extensible (or Exchange) Storage Engine.  Since this error was coming up on a server that was in the process of being decommissioned, the suggestion to “move the users to a new store” was extremely feasible.

But the problem came back 22 days later on one of the 2 stores that the users were moved to, so we knew something else must be up.  I’ll cut to the chase and explain that Microsoft now is very positive of what is happening, just not who is causing it or why it’s happening.

What’s frustrating about this is that all the tools that can be used to look deeper into this problem aren’t available to me as a technician outside of Microsoft.  All I’ve been able to do for my client is set up triggers to cause “Exchange store.exe dumps” which are essentially process freezes followed by private memory dumps to disk.  The good thing is that the end users don’t notice, nor does the Windows 2003 Cluster service.  Also, our Microsoft support team has been great at sharing information with us.

But the problem still remains, that there is nothing at all that I can do to fix this problem.  I can’t run the debug programs (I can run a debug against the process, but not to the same level of detail, due to a lack of published information) that Microsoft has available, despite a very deep understanding of how the ESE runs the EDB, STM, and LOG files (for an outside consultant who just reads voraciously).  This inability to better service my customers frustrates me to no end, whether Microsoft’s technicians are fantastic or not (there have been other times…).

So, while I wait for them to get back to me on yet another dump that has been generated, looking for a very elusive fSearch() operation against one of my client’s many Exchange 2003 stores, I sit on my hands in anticipation, wishing to be able to do more.