MDT Web FrontEnd – How To configure what a User can see and edit

January 25, 2010

In the last Post I showed you how you can use the MDT Web FrontEnd to restrict access to the MDT Deployment database. Following this you are able to restrict e.g. a Helpdesk User to only add and edit computers but that he/she can’t do anything else on Locations, Roles or MakeModels. But everybody who has access to the Settings of an Identity will still be able to see and maybe also change all Settings.

This raises several problems. A User might still be able to see more then he is supposed to see. He/she might even be able to change some settings he/she shall just be able to see. Or a User might simply be overwhelmed by the pure amount of available settings. MDT 2010 has at least 215 different settings after the base installation and even experienced MDT Users are sometimes a bit lost finding the proper setting to achieve the desired result. A lot of these settings apply only in specific circumstances (e.g. server specific. LTI specific, etc.), some are even deprecated. Additionally all custom settings are simply added to the last section of the whole list of settings if using MDT 2010. In MDT 2008 it wasn’t even possible to show custom settings without rewriting the Deployment workbench.

This said, wouldn’t it be nice to be able to create different subsets of these settings, reorder or re-categorize them? How about even renaming them or making only some of them writable? Or mixing custom with original Settings?

All this is possible with the MDT Web FrontEnd. Let’s have a look on how this can be accomplished:

Settings

A Setting is the basic piece in this concept. A single setting always references a column in the Settings table of the original MDT Deployment Database. No matter if it is an original or a custom setting. Each setting has a Name and can have an additional Description (The description will be shown when the Mouse hovers the setting in the FrontEnd). Additionally you can define if a setting shall be “ReadOnly”, meaning even if the User has the “Change” permission to all Settings he/she will still only be able to see this setting, but not be able to edit it. Some settings require specific values like “YES”, “NO”, “Y”, “ALL”, “TRUE”, “FALSE”, etc. Entering wrong values or even the right value in the wrong format can cause troubles when MDT tries to interpret the stored values.

Here a screenshot from the FrontEnd showing how you can create a “Setting” to be used in the FrontEnd. You will see that the FrontEnd has a couple predefined “Types” you can configure for a setting. “Text” will just end up as a simple Textbox, “Password” will also be a Textbox but not showing the individual characters of the text typed, TimeZone and TimeZoneName will show a Dropdown box with all Timezones and put the appropriate value into the database. “YesNo”, “YesNoAll” and “TrueFalse will also end up as DropDown boxes. This ensures that a User can’t type in the wrong values. There are more types to come i future releases, especially for the Localization part which can be quite complicated as it even depends on the Target OS what exact value to choose.

Groups

Finally we have Groups. A Group contains one or several Categories. This is so to speak the container for a full set (or Group ;-) ) of settings. The FrontEnd contains two default Groups “MDT 2008 Default” and “MDT 2010 Default”. These have been pre-configured with all Settings of MDT 2008 and MDT 2010 and create an identical look to the Deployment Workbench of each version (Yes the FrontEnd will work with both versions). So you might want to have a look on the existing configuration first before you start to create your custom views. A category can be used in several Groups. e.g. the pre-defined “Display Settings” category is used in both default Groups. But be aware, if you change something in this Category, it will affect all Groups this Category is used. So you might need to add a new category instead of changing one.

An Example

OK, let’s assume we have a couple of Helpdesk guys/1st Line supporters. They regularly set up new computers and also schedule re-images of existing computers that experience errors which would involve more time fixing the issue instead of just re-imaging the existing machine (assuming our standard image is well tested and we have a good mapping between installed applications and the standard applications we install on-the-fly).

These guys typically don’t need a lot of settings. As this is an example, we will even keep it more simple. So what do we want to make them available? Let’s say

- Computername (we assume it can’t be auto generated)
- User Data Share and User Data Directory (point to different place in case of replacements)
- Timezone

That should be enough to show the concept. Let’s start with the Computername. With MDT 2010 the formerly used (and still available) setting “ComputerName” has been deprecated. The setting we should use is “OSDComputerName”. Sure it’s easy to tell somebody to use this field if he/she needs to set the name of a computer. But wouldn’t it be better to still call it “Computername” in the FrontEnd and store the information into the appropriate setting in the database? OK, the FrontEnd will be able to do this. Let’s see how we accomplish that.

As mentioned already, we need to have a Category to logically group those settings. We just create a new Category and call it “Helpdesk Settings” (not fancy but should work ;-) ). To do this open the FrontEnd, click on the “Settings” tab and then on the “Categories” tab (this feature is so powerful that it got it’s own area :-) ). You will see a list of available Categories that is already quite long due to the default groups for MDT 2008 and MDT 2010. Anyway, click on “Add Category” and now give it a Name and Description.

After saving you will see the new Category. At the bottom of this you will find the mask to add new settings to this Category. The first Dropdown list contains a list of all available settings from the MDT Deployment Database. It will also include all Custom Settings you might have added (the FrontEnd will even give you the possibility to create new custom Settings without touching the Database. This will be shown in the next How-To). Now select the “OSDComputerName” from the list. Next we want to give it a more user-friendly name. We call it “Computer name”. The Description will be shown to the User, when hovering with the mouse over the field. That said we should always give some useful information. Let’s type “The new computer name to assign to the computer”. It’s a default field for simple text, so keep the “Type” on the default “Text” and don’t check the “ReadOnly”. Save your changes.

Now we do the same for all the other settings we have mentioned before. You will notice, that the OSDComputerName is no longer available in the list of settings. Choose UDShare, call it e.g. “User Data Share” with a Description of e.g. ”The UNC path to the User Data”. Keep it as “Text” and save. Choose UDDir, call it e.g. “User Data Directory” with a Description of e.g. “Directory that contains the User Data”. Again keep it as “Text” and save. Finally the Timezone. As we only deploy Windows 7 we use the setting “TimeZoneName” for this (Use “TimeZone” for XP). So choose it from the list of available settings, Give it the name “Timezone” with a Description of “The timezone of the computer” and now choose “TimeZoneName” from the “Type” Dropdown list. When later editing this setting, the FrontEnd will automatically show a Dropdown list of available Timezones. Click save and we have finished your new (simple) category:

The only option we haven’t used in this example is “ReadOnly”. When creating a Setting as “ReadOnly” it will be shown to the user, but he/she won’t be able to change it, even when editing the other settings. This will be helpful if you want to give them an easy way to look for an information already configure in the database, let’s say a password, network location, etc. but only a very small group of users shall be able to really change this value (those user would then have a different Group assigned to their Access Role).

You can change a category at any time and the changes will be available to the users instantly after you saved the changes on the next request of a page. You can add or delete settings, re-order them by simple Drag-And-Drop operations and you can change the name and description shown to the user. To change a setting, you would need to delete it first and then re-create it with the different configuration. The possibility for direct editing might be added later to the FrontEnd.

Ok, let’s finish this. We now have our Category. To be able to use it, we need to add this Category to a Group (yes, even if we have only one Category). So click on the “Settings” tab (if you have opened a different page in the meantime) and then click on “Groups”. You will see a list of available Groups. We want to create a new one, so click on “Add Group” and call it e.g. “Helpdesk Users” with a Description of “Settings for Helpdesk Users”.

After saving the changes we can add the Category by simply choosing it from the Dropdown list of all available Categories and “Save” it. Again, you can also edit any existing Group. All changes will be instantly available after saving the changes. You can add and remove Categories, you can re-order them and you can change the name and Description. As you can see on the screenshot you will also see all the settings available in each Category.

The last thing we have to do is to tell the FrontEnd which Users shall use this Group. To do this, we assign this Group to an Access Role. Ok, let’s click on the “Admin” Tab and then click on the “Access Roles” tab. In the last post, we created an Access Role for “Computer Editors”. Let’s assign the new “Helpdesk Users” Group to this Access Role. Click on the Edit-Icon to edit the Access Role

Now choose the “Helpdesk Users” Group from the list of available Groups. You can also rename this Access Role to “Helpdesk Users” if you like and save the changes.

All Users with this Access Role assigned will now use this Group when querying or changing the settings. For demonstration purposes I just assigned this Role to me on a test installation. This is a screenshot from the Settings of a computer:

The values shown might make more sense on the Settings for Roles or Locations instead for an individual computer but it shall show a concept and that the view a User get is restricted to what we have configured before.

It can become a bit complicated when Users are member of different Access Roles but as long as only one Access Role is valid in the current context it shouldn’t be a problem. So it’s up to you how you define your structure to avoid conflicts. I prefer to have another AccessRole instead of assigning a User to to many different AccessRoles. Typically there aren’t so many different User Groups. But that also depends on the size of your deployment. Most implementations I’ve seen so far have less then a dozen different Access Roles. Often there are some common ones like ComputerEditors, LocationEditors, RoleEditors, plus some additional slightly specialized ones. But heavily used is the feature described in this How-To as the combination of required settings is always different.

The combination of Access Roles and customized Groups is extremely powerful. It really ranges from Full Access for everyone to individual configuration per computer and user. But even more important everything in between. By creating a good access concept in advance you can increase the usability for users of different knowledge levels and also reduce the amount of possible errors.

Find the Download of the current Beta Release of the MDT Web FrontEnd on Codeplex. Also find more information about the topics described in this post in the (still growing) Documentation especially in the section Managing Groups, Categories and (Custom) Settings.

Be sure to get back to this Blog regularly as there are more How-Tos coming. The next one will cover the handling of Custom Settings. Also don’t hesitate to send me your feedback and comments or to discuss new features or problems on Codeplex.

The following How Tos have been published so far:

- How To restrict access to the Deployment Database

- How To configure what a User can see and edit

- How To handle Custom Settings

- How To create custom Lists to select pre-defined values for a setting

- How To handle MDT Applications in the FrontEnd

- How To handle SCCM packages