Austin Exchange User Group
Fellow MVP Chris Scharff and I are working on setting up an Austin Exchange User Group. Before we finalize plans on when and where we can meet, we need to be able to gauge interest in who can be there. I suspect we'll be able to harangue some of the other local MVP's from the Austin area to be there as well, so take this opportunity to let me know if you'd be interested in attending!

Please e-mail me at ben_winzenz@NOSPAMmessageone.com (remove the NOSPAM portion) to indicate your interest. We will likely be holding meetings on Tuesday evenings at 7pm (unless that works out to be a bad time) roughly once a month.

Please feel free to pass this on to any others you know. We'd like to have a good showing. The format of the first meeting will likely be open, with some discussion (perhaps a short presentation or demo) on new features in Exchange "12" along with an open-panel discussion on issues you are facing or questions you have about Exchange.

If you have any suggestions for topics you'd like covered, please include those in your e-mail to me.
- posted by Ben Winzenz @ 10:09 AM 1 comments

 
Disappointing news from Microsoft
Yeah, I know. I usually write good things about Microsoft. I'm fairly entrenched in Microsoft technology, and on the whole, it's pretty good. I get along with it pretty well, at any rate. This, however, is one thing I just don't understand.

First, I have previously written about Stringbean Software's iscsi Target server software labeled WinTarget. It provided iscsi server functionality, allowing one to define new targets (viewed as LUN's) both using file-based targets, or volume-based targets. It has worked very well for us and has allowed us to achieve SAN functionality (shared storage being the key aspect here) at a much lower cost than a traditional SAN with fiber connectivity.

I recently found out that WinTarget had been acquired by Microsoft, and that Microsoft was integrating the WinTarget functionality into Windows Storage Server 2003 R2. That, I thought, was GREAT news. Now for the bad news. As with the original release of Windows Storage Server, WSS R2 will ONLY be available through OEM's. This means that in order to get WSS R2, you will have to buy a new server. Oh, and not just any server. There are only certain models of servers that OEM's will bundle with WSS R2, so you can't just get it with any server. This to me means that you can no longer use it as you previously could. Reducing availability is usually NOT a good thing.

Why is this so disappointing to me? For one, since WinTarget has been acquired by Microsoft, although it may not be impossible to acquire new licenses of the standalone WinTarget software (Stringbean's website says to contact a Solution Provider or OEM solution partner), it's certainly going to be harder. Having looked at most if not all of the partners they list, none of them list the WinTarget software as a separate SKU. Just about all of the partners are storage partners that sell SAN's.

I had really looked forward to seeing how WSS R2 worked with iscsi target functionality built-in. It doesn't look like I'll get to try it out any time soon. Those of you that get to play with this - please let me know how you like it.

Oh, Shola Aluko blogged about this yesterday here, but my comment hasn't shown up yet, which is making me wonder if they moderated the comment and refused to post it. Note: It wasn't an obscene comment - I don't do those. I'll check back later to see if it ever shows up.

Update: Yes, my comment finally showed up. Now you can see it really wasn't too inflammatory. BTW - it seems some of the other iScsi software vendors are viewing this news about WinTarget as an extremely rare present that has just been dropped in their laps. That seems to cement for me that WinTarget was likely the leading software-based iscsi server solution. That just makes this more disappointing to me, as the end-user who doesn't wish to buy a new server will now have to settle for second-best.
- posted by Ben Winzenz @ 9:19 AM 0 comments

 
Outlook 2007 and Exchange 12 autodiscovery
Let me say just one thing. It's very cool. I've got an E12 Mailbox server deployed that also hosts the Bridgehead and Client Access roles. I've also got a machine running Vista build 5342 with Office 2007 Technical Refresh on it. Office 2007 now supports automatically detecting your server settings. I have seen this before, but since Exchange 2003 doesn't support it, I haven't had a chance to use it.

So I'm setting up my Outlook profile and you have a choice of whether to manually configure server settings, or whether to have them automatically detected (automatic detection is the default). Wonder of wonders, since I was logged on with the account that had the mailbox, and since Exchange 12 supports autodiscovery, Outlook automatically configured itself without me having to do anything at all. I started to type in my name, and before I had finished typing more than a few letters, my full name and my e-mail address had automatically been filled in. See, the way that autodiscovery works is that Outlook contacts the Client Access server (which has a special http virtual directory) and presents the username and e-mail address. With that information, the Client Access server then sends back an xml file with the configuration settings and Outlook automatically configures itself.

The autodiscovery feature should make it possible for folks to using RPC/HTTPS to set up their profile from wherever they want without going through the fuss of manually entering all the information (which can be a pain) as long as a Client Access server is available for them to talk to. I'll be testing the RPC/HTTPS functionality as soon as I can. Of course, as noted above, autodiscovery works greate for regular mailbox users as well. It should reduce support time involved with assisting users in setting up Outlook profiles. Kudos to both the Exchange and Office teams for implementing this feature.
- posted by Ben Winzenz @ 9:39 AM 3 comments

 
Exchange Activesync and SBS
I don't work with Small Business Server a lot, but I found some interesting information this morning that I thought I would share. For many, configuring Server Activesync can result in a lot of frustration. This does not just apply to SBS. There are a lot of settings that have to be configured in order for this to work.

One common scenario where Activesync can be problematic is where you have enabled Forms-based authentication for Exchange, and have only one server. The problems this causes are actually quite well documented here. The main issue here is that the Activesync virtual directory expects to talk to the Exchange virtual directory via http, not https. If you have forms-based authentication enabled, and are requiring ssl, activesync (and oma) will not work. The solution is to create another virtual directory according to the instructions in the KB article above. The nice thing about SBS is that this is done automatically as part of the SBS customization. Here's where it gets tricky. In addition to wanting to talk over http, Activesync also expects to use Kerberos authentication. If Integrated authentication has been disabled on the Exchange virtual directory OR the new exchange-oma virtual directory, then you will see the same HTTP_500 error indicating there was a server error and activesync will fail.
- posted by Ben Winzenz @ 8:22 AM 2 comments

 
Great news for Exchange Administrators!
I just saw this today posted on Gerod Serafin's blog. The Exchange team has posted a new KB article detailing a hot fix (yes, you still have to call in and get it, no you won't be charged for the call) that is now available to deal with disabled user accounts.

Prior to this hotfix, the default behavior was that as *soon* as you disable a user account, ALL mail will immediately begin to NDR. This is because disabled user accounts do not have a valid msExchMasterAccountSid attribute.

There used to be 2 methods to fix this (both arrived at the same solution, but one was automated). The first was to manually edit the ACL's on the account (Mailbox Rights) and grant the SELF account Full Mailbox Access and Associate External Account. This would fix the missing msExchMasterAccountSid attribute and allow the mailbox to again receive mail. The second method was to obtain a tool called NoMAS (No Master Account Sid) and run it. It would then automatically fix any and all accounts in the domain with this missing attribute.

I have always disagreed with this default behavior, so I am quite happy to see this hotfix available. It will change the behavior of Exchange so that it automatically uses the SELF sid as the msExchMasterAccountSid for disabled accounts. Read more about this hotfix from the following KB article.
KB 903158

Update: It has also been posted on the Exchange Team's blog, courtesy of Nino Bilic and Alex Seigler (Alex was the original developer of the NoMAS tool). Thanks go out to all those involved in publishing this hotfix.
- posted by Ben Winzenz @ 10:59 AM 0 comments

 
Disaster Recovery Preparation
If you are still running Exchange 2000, you probably know that disaster recovery preparation has changed quite a bit in Exchange 2003. For instance, the introduction of the Recovery Storage Group now makes it much easier to recover mailbox data for individual users, and no longer requires you to build a recovery Exchange server (in a separate forest, or segmented network).

Let's go back and take a look at building a recovery server for Exchange 2000, though. There are really two choices when you implement a recovery server. First, you can take an existing GC offline and move it to a segmented network that has no access to your production server. Once you have done this, you will need to seize all the FSMO roles. Then you can install Exchange on another server (using the /disasterrecovery switch if you want) that has the same name as the original Exchange server. If you choose this method, you won't have to worry about legacyExchangeDN issues, as the /disasterrecovery switch simply pulls all the Exchange info out of Active Directory and doesn't prompt you for any information. HOWEVER, one key warning here. If you have deployed an empty forest root domain, and all your accounts are set up in a child domain (as well as Exchange), you also have to put a forest root GC in your recovery network. See, one of the FSMO roles is the Schema Master. That specific role can only be assigned to one server in the entire forest. In order to seize the Schema Master role, you have to be logged on with an account that is a member of the Schema Admins and/or Enterprise Admins Groups. Guess what? Those groups do not exist in a child domain :-) If you forget to put a forest root GC into your recovery network, you will not be able to reinstall Exchange because you will not be able to seize the Schema Master role. Which brings you to the second choice (and the one actually outlined in Microsoft's Mailbox Recovery white paper - found here).

The second method is to build a completely new forest (the AD domain name simply doesn't matter here as it relates to Exchange). For this, you can even use a single server to do everything. This also gives you the added benefit that you can leave it attached to your production network if you choose (certainly makes restoring from tape easier) Build your forest (new forest, new tree, new domain), then install Exchange using the same Organization name as your production org (and SP's to same level as production server). Once you have done that, you'll need to make sure that the legacyExchangeDN's match those of production (this information is detailed in the white paper) and then create the Admin groups and Mailbox stores so that they match production as well. Now you are ready to restore. You can either restore using your backup software (if this is a possibility), or you can also simply restore the flat files (.edb and .stm files). Either way works fine. Now you are ready to mount the store. If everything was done correctly, the store will mount without any problems. IF there are any errors, consult event viewer (Application log) for more details. The most common reasons that the store wouldn't mount would be if a legacyExchangeDN value does not match somewhere. There is a great tool on the Sp3 CD to help with this - it is called LegacyDN.exe. It basically allows you to change the LegacyExchangeDN value for your Administrative Group (and all objects underneath it if I understand the tool correctly). It can come in quite handy if your production environment had been migrated from Exchange 5.5.

With either the first or second method, once the mailbox store is mounted, you are ready to use Exmerge. A couple of notes on using Exmerge.

1. There is some conflicting information out there regarding whether or not Outlook is required. I do not recall ever needing Outlook on a recovery Exchange server, but there are other KB articles that mention Outlook should be installed. I'll leave it up to you.
2. If you run Exmerge, remember that it requires RECEIVE AS permissions on the mailbox store object in order to be able to extract.
3. The user account you are logged in with MUST have a mailbox on a store that is mounted. If the user account has a mailbox, but that mailbox store is not mounted, Exmerge will be unable to log in and see the other mailboxes on other stores.

As you can see, recovery prospects for a single mailbox for Exchange 2000 can be quite difficult. If you are looking to recover a single mailbox and don't do mailbox-level backups (which I don't recommend anyways), you might consider deploying an Exchange 2003 server and working with the Recovery Storage Group. Remember that as long as your Exchange 2000 database is SP3 or greater, you can still mount that database to the Recovery Storage Group in Exchange 2003.
- posted by Ben Winzenz @ 8:15 AM 0 comments

 
I'm sorry that I have to say this
Let me start by saying that I usually shy away from discussing political issues in my blog. This topic, however, I felt was too important to keep quiet about.

I am extremely disappointed in our country’s politicians, but really, should I have expected less? I was very disappointed to hear that Dubai Ports World, the Dubai shipping company based out of the UAE that was set to take over management (key word there is management) of some of our ports, was in essence forced to pull out of the deal and will no longer manage operations for those ports. Instead, they will turn over all management functions to an American company. They claimed that the relationship between our two countries was too important, but I fear that the relationship between our two countries has already been damaged by this fiasco.

After all that our country has been through, I submit that we are just as bigoted as the extremist Muslims. After all, we are now punishing ALL Arabs (or at least it appears that way) for the crimes of a few. We are saying that, even though these same ports had been (gasp!) managed by another country for years, that having them managed (not operated) by a country full of Arabs just wouldn’t do. This is racial profiling of the worst kind – the very thing that we fight so hard to prevent inside our country. After all, that would give an upstanding company that, might I add, manages operations for ports ALL OVER THE WORLD, access to allow terrorists to exploit this as a “weakness” in our nation’s security. Yes, a weakness, even though day-to-day operations, and security, would still be performed by Americans

No, instead, this round goes to the terrorists. Why, you say? Oh, this is exactly what they wanted. They want Everyone to see that America doesn’t want to do business with Arabian nations. They want Everyone to see just how intolerant we are (yet we can call Muslim extremists intolerant, and that’s ok). Unfortunately, we’ve played right into their hands. I just hope that this doesn’t damage our relations with other Arab nations too much. I also hope there isn’t much international backlash because of this, but if there is, I can hardly say that we don’t deserve it

I respect your right to disagree with me (if you do). This is my opinion, and I stand by it until such time that it can be proved this isn’t what happened.
- posted by Ben Winzenz @ 9:28 AM 1 comments

 
Hacking your Windows Mobile 5.0 Registry
Sounds like a great start to a post, huh? OK, here's the deal. I've blogged a few times about my Jasjar (yes, I still love it and use it almost every day).

Devin Ganger at 3Sharp blogged about the inability to add Root SSL certificates on some WM 5.0 devices, which is true. What isn't mentioned much of anywhere (you have to look around pretty hard) is that you actually can still disable Certificate Checking - you just can't use the old DisableCertChk tool from Windows Mobile 2003. Microsoft doesn't recommend this, but it's a necessary evil in some situations. Two that I can think of are:

1. Your company uses a Wildcard SSL Certificate. (i.e. *.company.com). Windows Mobile 5.0 (or any other version for that matter) does NOT support wildcard certs. Why, I'm not sure, but it doesn't.
2. You have a manufacturer locked device that prevents you from adding additional Root Certificates. Again, WHY a manufacturer would prevent folks from adding additional root certificates is beyond me, but it happens.

So, on to the registry hacking.
First, you download my new favorite freeware Windows Mobile Registry editor, PHM registry editor, which I blogged about earlier. The ONLY catch with this program is that it may not install correctly on newer devices. What I ended up having to do was install the program on my desktop (which just extracts a bunch of cab files), then go to the install directory, grab the cab files and copy them to my device. The one that ended up working for me was the cab file named regedit_Mrln_ARM.cab. Simply click on the file from your windows mobile device, and it will install it. Once it is installed, you can delete all the cab files from the device.

Surprisingly (or not), the registry on Windows Mobile devices is very familiar if you have ever looked at the registry on a regular PC. Anyways, to disable Cert Checking, you navigate to the following location:

Hkey_Current_User\Software\Microsoft\ActiveSync\Partners

Here you should notice 2 sub-keys, both with a unique UID. One is set up for the ActiveSync Partnership with your PC, the other is set up for the partnership with your Exchange server. Fortunately, it is fairly easy to distinguish between the two. Simply highlight one of them, and look at the different values. You'll see pretty quickly which one is for your Exchange server. While the partner key for your Exchange server is highlighted, create a new value with the following parameters

Type: DWORD
Name: secure
Value: 0

That's all there is to it. You have now successfully disabled certificate checking on your device and can now have ActiveSync use SSL with wildcard certs and self-signed certs.
- posted by Ben Winzenz @ 1:24 PM 50 comments

 
I Want This!
LG Philips has developed a 100-inch LCD Television. Yikes!

While it is most certainly overkill for virtually any home, it would still be fun to have...
- posted by Ben Winzenz @ 9:45 AM 0 comments

 
Do you have an MSDN or TechNet Subscription?
If so, Microsoft announced today that they will make Beta 1 of Exchange "12" available as a CTP to MSDN and TechNet subscribers. I don't have all the details or know if it is being made available to ALL levels of subscriptions, but if you have one and are interested in trying Exchange 12, make sure to sign in to your Technet/MSDN account and see if it is available in your downloads. According to Paul's blog, MSDN subscribers will see it available starting today, while Technet subscribers will see it available as part of their March bits.

You can find more information about Exchange "12" on Microsoft's site
- posted by Ben Winzenz @ 2:39 PM 0 comments

 
Get yer USB key from Microsoft
While supplies last.

Go to http://www.microsoft.com//windowsxp/mysterysolved/corp/default.mspx and click on the "Get Yours" link. You have to have a Passport account, and you have to fill out a brief survey. Allow 6-8 weeks for shipping.

I don't know how big this USB drive is, but hey, can't hurt to have another USB drive laying around, right?
- posted by Ben Winzenz @ 10:07 AM 1 comments