My blog will be moving
With the recent issues I've encountered here at Blogger since moving to the Beta service (the inability to publish from Live Writer or Word is a big one), and since my joining Microsoft, I've decided to move my blog over to Technet blogs. There may be occassional posts here in the future, but most of my content will be published to my new blog. You can find my new blog at:

http://blogs.technet.com/benw/

Make sure to update your bookmarks and your RSS subscriptions.

I've already got one post up there - let me know what you think of it, and also if you have any ideas for future topics.
- posted by Ben Winzenz @ 2:41 PM 0 comments

 
Three items of note in the Sports world
First, the Bears offense didn't deserve to win last night against the Arizona Cardinals. Rex Grossman was terrible. 4 interceptions, and 2 lost fumbles. That's almost unheard of. However, give credit to the Bears defense. After being down 20-0 at the half, they came back to life, and literally got their team back in the game. They forced 2 fumbles that were returned for touchdowns, and with a punt return for a touchdown and a lone field goal earlier in the game, that's all Chicago needed. We'll see how they rebound from this dismal performance, but they certainly didn't look like a potential 16-0 team last night.

Second, I am absolutely disgusted at the brawl that occurred during the Miami - Florida International game this past Saturday. It was a debacle. It was an embarrassment to both schools. At least one of them seems to be taking it somewhat seriously. Unfortunately, it isn't Miami. Florida International dismissed 2 players, and extended the suspensions of 16 others to indefinite suspensions. Miami, on the other hand, has suspended one player indefinitely (the one that was swinging his helmet at other players), but 13 other players only received a 1-game suspension (including a player that was visually observed to be "stomping" on other players legs. You gotta be kidding me. Mike and Mike (on ESPN radio) are spot-on when they said that the players involved (or at least those that committed the more serious acts) should be kicked off their respective teams, and should then be banned from football for life (including the NFL). The piddly 1-game suspensions dished out by the conference (ACC and Sunbelt) and by Miami are nothing more than token penalties. ACC commissioner John Swofford says "These suspensions send a clear and definitive message that this type of behavior will not be tolerated," - yeah right. Gimme a break. At least FIU had the guts to make a strong statement by indefinitely suspending many of the players involved.

Third, I Believe! Actually, I guess I should say I'm a fair weather fan. Let me explain. I grew up near Ann Arbor, MI. We'd usually go to a few Detroit Tigers games per year, though I don't remember going to any games until after they won the 1984 World Series. I remember players like Chet Lemon, Alan Trammel, and Jack Morris. I remember the old Tiger Stadium. I remember that most years, the Tigers stunk, and didn't make it to the playoffs. In fact, they haven't been in the playoffs since 1987. I suppose it's no wonder, then, that I never declared myself a true fan. So when they squeaked into the playoffs this year (after blowing a rather large lead towards the end of the season) and were matched up against the New York Yankees, I didn't give them much chance of advancing. But they did! Then, they swept (yes, swept) the Oakland A's by winning 4 games in a row, and advanced to the World Series, where they await the winner of the NY Mets and St. Louis Cardinals. Could this be their year? I mentioned to my wife the other day that I hadn't heard of the names of any of the players, and her comment was that meant that they were a true team, with no real standout players. I think that's pretty accurate. Go Tigers!
- posted by Ben Winzenz @ 8:21 AM 0 comments

 
Outlook Delegates issues
If you aren't familiar with the Outlook Delegates functionality, it provides you with the ability to specify a Delegate for your Mailbox. Delegates can perform items such as sending items on your behalf, and responding the meeting requests, etc. When you add a delegate, you can specify that they receive copies of your meeting requests, which is quite typical.

Now, say you have a few delegates, and one of them leaves the company. Your IT staff diligently deletes the account (and mailbox). However, all of a sudden, meeting requests to you now generate an NDR. The cause? Delegates. For whatever reason, Outlook stores delegates separately (they are actually stored as a hidden rule on your mailbox), so that if you delete a user account that was set as a delegate, Outlook doesn't automatically remove that delegate. Ok - this is easily fixed. You need to go into Outlook, Tools, Options, Delegates, and remove the non-existent user.

What if you've already done that, and nothing shows up in the Delegates tab?
http://support.microsoft.com/kb/253557/en-us comes to the rescue. The KB article talks about a little different situation, but one that applies nonetheless. The problem is that this "hidden" rule has become stranded. You can't see it (with Outlook), but it's still there, and still functioning. The solution is to use the Mdbview utility to log on to your mailbox. If you've never used mdbview before, a word of caution is that the output is pretty ugly! Anyways, after logging on to your mailbox, the instructions have you go to your inbox and find the message that has Schedule + EMS Interface in the description, and then delete that message. Normally, this should remove the delegation, but you still want to go back into your Outlook settings and check. In some cases, you may now see an Unknown account in the delegation, at which point you can remove it.
- posted by Ben Winzenz @ 3:34 PM 2 comments

 
SBS Migration hell
I recently helped a friend with a swing migration from one (really old) SBS 2003 server to another (new) SBS 2003 server. As there is currently NO process provided by Microsoft to migrate SBS servers (at least none that I am aware of), my friend had purchased the SBS Swing It Kit, provided by Jeff Middleton (SBS MVP) to assist us in this project.

SBS (Small Business Server), if you haven't worked with it before, is designed for small businesses and is also designed to run on 1 server. As such, your 1 SBS server is set up to host many roles on the same box - we're talking Active Directory, Exchange, SQL, Sharepoint, and optionally, ISA and some others. There are license limits in place that only allow you to have a certain number of clients (I want to say 75?), which is why it should only be used for small businesses.

On to our experience. The SBS box in question was just running SBS Standard, which probably made it a "little" bit easier, but not much. A brief overview of the swing migration process is that you have to bring up a temporary DC, transfer everything to that, remove all references to the existing DC, then add your new server (which has the same name as the old server) back in. This by no means details all of the steps involved (which are quite numerous), so I'd encourage you to check out the Swing It kit previously mentioned if you have to go through this process. Anyways - adding the new server didn't pose any problems. AD and DNS replicated with no issues and we were able to do the things we needed. The problems began when we tried to add the new server (with the same name as the old one). We couldn't get AD to replicate. After a few hours of mucking around, we found the issue. Ready? It was the Windows Firewall service! Why on earth the Windows Firewall would decide to prevent Active Directory replication is beyond me, but it did. Once the service was disabled, replication took place within a few minutes and we could then proceed.

Probably the most difficult part about a migration like this is getting the Exchange data transferred. Luckily, as long as the server name (along with a few other things) is the same, you should be able to mount the database from the old server with no issues. I've done this several times for regular Exchange servers, and it's the method that you used to have to follow with Exchange 2000 (build recovery Exchange server in a new forest that has same name, same admin group, same database name, etc.). However, another catch was that there hadn't been a successful full backup in a few weeks, so there were LOTS of log files. To be on the safe side, we brought those over as well, even though the stores were in a clean shutdown state. The biggest nightmare for us was actually getting the stores to mount, though. Let me state for the record here that at 4am in the morning, patience is not my strong suit.

I had applied Exchange 2003 SP2 while I was still copying the databases and log files from the old server to the new one (hooked up old drive via USB 2.0 enclosure), and even though the stores were dismounted when I ran the SP, after it was done, it tried to mount the stores, and replay all the log files. This *obviously* wasn't going to work, as the databases didn't even exist yet! Anyways, to make a long story short, I killed the store.exe process so the SP install would finish. Once that was done, and the stores and logs were transferred, I tried to mount the stores, only to have it fail with some comical error about files not being in the right state, or some such nonsense. I re-transferred the databases and logs again, and verified the databases were still in a clean shutdown state (eseutil /mh), but no dice. Running out of time, I thought I'd try to re-run SP2 and see if something had gotten mucked up the last time. This time, like the last, it replayed all the log files, then it purged them (I don't think I've ever seen an SP purge log files - hehe). With that done, all I had to do was mark the databases as being able to be overwritten, then I was able to mount them successfully.

The other problem we encountered was with the migration of the shares. Because there was a lot of data in the user shares, we decided we didn't have enough time to move the data, so we hooked up the old hard drive into the new server, and re-created the shares. Though I could have sworn that we checked, apparently the new share for the User Shared Files (where My Documents gets redirected to) was set to share perms of Read only. Remember that Windows uses the most restrictive set of permissions when you are accessing a share, so even if you have full control at the NTFS level, if your share permissions are read-only, you aren't going to be writing anything to that share, bucko. That was easy enough to clear up.

Sooo - 12 hours, and a severe case of sleep-deprivation later, migration is done. A few minor problems cropped up later on, but my friend was able to take care of those.

My observations:
1. Why in the world does an SBS migration have to be this difficult?
2. Has anyone at Microsoft tried to migrate SBS servers? If so, do they expect small businesses to ever do this without hiring an sbs expert?
3. I don't like SBS. I really don't. Some people love it. I'm not one of them. It felt like a very dummified [1] version of Windows Server 2003, with wizards galore, and progress bars that leave no indication of what exactly it is doing.

I've promised myself to never touch another SBS server, and above all to never do another SBS migration. I'll leave those to the SBS experts, something which I don't claim to be.

[1] I think I just made up a word.
- posted by Ben Winzenz @ 11:00 AM 6 comments

 
Status Change for me
As of Monday, Oct. 2nd, I have now joined Microsoft as an Exchange Support Engineer. I'm not sure yet what that means for this blog, so for the time being, I will continue to post new content here. If the location of my blog changes in the future, I'll be sure to post an update.
- posted by Ben Winzenz @ 10:56 AM 0 comments