Know your wizard's

As part of a recent migration. I wondered over an interesting issue, with none other than the helpful SBS Wizards.

The problem really had it's roots in that the previous support company had failed to really understand and correctly deploy SBS 2003.

As part of the migration process, the SBS 2008 Wizards are run. These 'fix', amougnst other things, the Internet Explorer homepage and WSUS policy and membership. Unfortunately, the customer did not have a good history of patching their PC's, nor did they like www.google.com being replaced with CompanyWeb.

Another simple tip, know what the SBS Wizards will do. For example, rerunning the Internet Address Management Wizard resets the default homepage back to companyweb.

In this case, we simply created new Group Policy to enforce the Internet Explorer settings we wanted. As best practice, we never make changes to the default Group Policy.

EDIT: Interesting reading from new posts from some notable MVP's

Susan Bradley

Response

Wizards mischief

A warning regarding the SBS User Roles and Change User role wizard.

I really like the concept of the User Role in SBS, it reminds me of the organisational role in Novell eDirectory. The real advantage here is you can assign a user a role, and the quotas, permissions and group memberships are automatically applied to that user. Need to make a site wide change to a group of users, simply change the role and these are reapplied to the users assigned that role. Easy.

However, I have been dealing with a number of migrations lately. This is where the user roles can become problematic. When migrating users to SBS 2008, the change user role wizard will safely add the settings for the role and assign it to the selected users. However, when making changes to the role, applying the changes will remove that user from any other groups they had membership of.

Bugger. My simple piece of advise, never change a user role in SBS. If a change is required, create a new role based on the original and use the change user role wizard.

Aother blog post on this subject here

SBS Blog here

Technet article here

Change control

This Friday I will be addressing our internal team on the importance of change control and change management processes. I have been singled out due to my recent 'experiences' in this area.

This is especially critical on systems such as Microsoft's Small Business server product. SBS is a complex entwinement of a number of Microsoft technologies (a number of which MS recommend are not placed on the same server). Even the simplest change can cause untold late nights for the responsible individual.

Form an engineers perspective, I always feel the pull to getting my hands dirty, instead of following proper process. However, this somewhat casual approach is not without it's consequences.

Formal change control processes can become unwieldy, and by their very complexity discourage use. However, a simple framework can provide a invaluable 'sanity check'. My bullet points:

Make sure it's not broken first.

Does it work properly in the first place? Patching a server is a brilliant example of this. Take for example, an SBS server with a lingering port issue, such as that introduced in ms08-037

Do you have a backup?

Do you, really? And is it any good. Any change, no matter how basic, always has the potential to go rouge. Sometimes you will need to roll back, and you need to be confident that you can. I am fortunate enough to have access to Shadow Protect for taking point in time backups prior to undertaking any work.

Have you thought about this?

What (or who) could be effected?

Is there a plan B?

Are you sure?

First Post

Hello and Welcome,

This shall be my blog about SBS and other such IT wonderfulness. Susan Bradley's post inspired me, especially after my recent disaster recovery and change control processes.

Hopefully it will serve me, and maybe a few others, well.