Much thanks to Mark B. for the catchy phrase in the title!

SBS 2008, by default, enables some security measures on mobile devies hiwhc use ActiveSync. These security measures are, of course, entirely appropriate for keeping valuable information on NSA employees’ handheld devices secure.

OK, OK, these measures might even be appropriate for the medical field, legal, banking, and a number of other fields.

However, you may have a client who does not want/need/like them. They may become particularly grumpy if these policies are suddenly pushed down to their handheld without warning after an SBS 2008 upgrade.

Here’s how to find and adjust them:

1. Open Exchange Management Shell.
2. Expand Organization Configuration.
3. Select Client Access.
4. Right-click the Windows SBS Mobile Mailbox Policy object and click Properties.
5. General Tab:
   • By default, “Allow non-provisionable devices” is checked, so that’s OK.
6. Password Tab:
   • There are a number of settings in here to adjust, most notably whether or not a password is required on the device, how many characters it must be, and whether it can be “simple” or not. The context-sensitive help is amazingly unhelpful regarding what a “simple” password is, but if you click the link near the bottom labeled “Understanding Exchange ActiveSync Mailbox Policies”, you get a better description, albeit not a comprehensive one. It simply (pun intended) says “This setting enables or disables the ability to use a simple password such as 1234. the default value is $true.”
7. Sync Settings Tab:
   • Another marvelously well-thought-out move by Microsoft is to set the default to include ALL past Calendar and E-Mail items, and allow attachments. Rumor has it they took money from flash memory card manufacturers for that setting.
   • On my Windows Mobile 5 device, I seem to be able to override these settings, and they do not get set back during the next sync. YMMV.

Alternatively, you could simply delete the entire policy. I suspect that if you did this after the settings were pushed out, the handhelds would not be able to be adjusted until they were reset to default, or until you created a new policy with all settings unchecked or something similar.

Probably the best solution is prevention - disable HTTPS through the firewall during the migration until you have had a chance to adjust these settings or remove the policy.

Tags: Activesync, Mobile Mailbox Policy, SBS 2008, Security

There is a new security feature in Windows 2008 and SBS 2008 called LUA (Local User Administrator). Basically, it’s another effort to break away from the time-honored tradition of logging into the computer with an account that has absolute control, when it is not necessary to do so. As malware becomes more sophisticated, it is increasingly dangerous to do so.

This latest feature has some definite drawbacks for the unaware though. You can find yourself unable to do certain administrative tasks, and not know why not. After all, your account is in the local administrators group. Heck, it’s even in Domain Admins, Schema Admins, and Enterprise Admins! Your account is effectively a god, and yet you can’t run a command-line backup.

I ran into this the other day on an SBS server, using the “wbadmin” utility. I got errors indicating that my permission level was not high enough, yet my account had all of the attributes listed above. It was, in fact, the admin account created for me by the SBS wizard. The actual “real” Administrator account was disabled - a default feature in SBS2008.

So in order to run the wbadmin utility, I had to enable the Administrator account, change its password so that I knew what it was, and then use RunAs to run the utility.

This is not so bad on the surface of things. It’s good security, and tolerable if you know about it. That’s where it all falls down though. None of the documentation I found regarding wbadmin, whether related to Windows 2008 or SBS2008, mentioned LUA or the fact that the real Administrator account was the only one I could use to run the commands they were telling me to run, nor that the account was in fact disabled.

I think we need a little work on that documentation, MS.

Tags: lua, runas, Security, wbadmin