One of the more powerful features of SBS 2008 is the User Role concept, based on the roles that were available in previous versions of SBS. These Roles are like account templates that can establish a common group of settings for one or more users in the network. Unlike the SBS 2003 Account Templates, however, the SBS 2008 User Roles are much more active, and if you”re not careful, you can get yourself into unintended trouble.
Let”s take a trivial example. You have a user with a large mailbox, and you don”t want that user subject to to the default Exchange mailbox quota. You go in and modify that user”s settings in the SBS console, and that user now has no Exchange quota. Super.
Down the line, you learn that you can modify the folder redirection settings for users by modifying the User Role. So you go into the Standard User Role and update the folder redirection settings. You save the changes to the role, and when you do, it lets you know that it”s going to apply those changes to all the users who have the role assigned. Great, that”s exactly what you want. Life is good.
Suddenly,you get a call from the user with the large mailbox and that user tells you that he (or she) can”t send or receive e-mail. Oops! When you reapplied the role,you inadvertantely reset the Exchange quota for that user. So you wipe the egg off your face nad go take care of that.
Unlike when you run the Change User Role wizard and have the option to Add To or Replace the user”s settings when the role is applied, if you make a change to the Role, any user who had Role settings modified from the Role defaults will have those custom settings overwritten. Working with Roles is not like working with Security Groups in AD, where you can adjust certain settings for one group and not impact other settings. All settings contained within a role get pushed back out to the users who have the role assigned when you make changes.
So what”s an SBS admin to do?
First, get out of the habit of having custom settings based on a user if you”re going to be using Roles (and I”m not suggesting that you shouldn”t use Roles, I”m just saying that you need to know what you”re in for if you do). If you have a user, or a group of users, who have one setting different from one of the standard roles, create a new Role for those users and modify the settings for those roles. In the example of the user with the large mailbox, you could create a new role based on that user”s settings and call it something like Standard User with No Exchange Quota. Then if you need to add a new user who also needs to have no Exchange quota, you assign that new user to that new Role.
Second, document the changes that you make. Nothing can cause you embarassment with a client quite like making a change from the “default” settings, then making another change that impacts the undocumented change, ending up with the user unable to send and receive e-mail, for example. The more you document, the greater the likelihood that you won”t end up with unexpected results. OK, that”s a bit of a pipe dream in this industry, but still, any documnetation is better than no documentation at all.
My recommendation for how to approach using User Roles in SBS is to leave the three roles created by SBS alone and create new roles for any customzations you want to make. Have a new user that needs no special configuration? Make them a Standard User. Have someone who needs folders redirected? Change them to the Standard Users with Folder Redirection role. If their mailbox grows larger than the default quota, add them to the Standard User with Folder Redirection and No Exchange Quota role. Could that get ridiculous before long? Absolutely. But if you come up with the configurations you want and create roles for them, your management life will get a LOT easier than if you have individual users with custom user settings that might get modified if you accidentally change a role.
Now is the time to think about these things, not after you”ve started an installation of SBS for a client. And certainly not after you lock the big boss out of his (or her) e-mail.