Maik Koster at myITforum.com

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

- How To restrict access to the Deployment Database

MDT Web FrontEnd – How To handle MDT applications in the FrontEnd

maikkoster — Fri, 05 Mar 2010 10:05:00 GMT

The Problem

One of the main drawbacks of the MDT Web FrontEnd (there aren’t many ;-) ) is, that it does not have direct access to the Deployment Share(s). Normally that wouldn’t be a problem as most of the settings don’t interact with anything stored in the Database. Except applications imported into MDT. As you know you can import Applications into MDT and use them in your Deployment. As long as you choose them directly in the LTI Wizard no problem. But what if you want to add those applications to the database?

Possible solutions

You could type them in. Probably possible and the Beta 2 of the FrontEnd was just offering a single textbox for this. I have to admit, it was a bad idea as MDT is referencing each application internally using a GUID (Yes, one of those unhandy, 32 character long thingies). Ok, time to improve it. How could we solve this?

The long term solution is probably to add some Powershell capabilities into the FrontEnd and let it communicate directly with a MDT Deployment Share to get the necessary information. As this is not as easy as it sounds, I choose an intermediate step for the first release of the FrontEnd. You simply import an existing Applications.xml file into the FrontEnd. The Applications.xml file can be found on each Deployment Share in the Control folder and stores the information about all applications available in MDT. The FrontEnd will read this file and import parts of the information into a table in the MDT Database making it possible to select those applications in the FrontEnd instead of typing them in.

An Example

Let’s see an example.

Open the MDT Web FrontEnd, click on the Admin and then on the Applications tab. If already imported you will see a list of all currently available applications. This will be a merged combination of all Applications imported into the FrontEnd using the Applications.xml file and all other applications configured either by hand or by the MDT Workbench. All Applications not imported yet will be shown with their GUID value.

OK, to import the Applications.xml file, click on the button labeled “Upload MDT Applications.xml file”.

On the following screen, click on the Browse button to pick the appropriate file (as said you will find it in the Control folder of a MDT Deployment Share). Then select if you would like to fully synchronize or just update the the applications. The difference is, that a synchronize will also remove applications no longer in the applications.xml file from the Database including all references to it. An update will keep those old entries. Generally a synchronize is the right option as you probably don’t want to use applications no longer available in MDT itself. But the update might be an option if you need to import several files if you use the same database from different Deployment points with different applications. Should not be common but it is possible. Click on "Upload” to start the import.

The import shouldn’t take much time and after it you should be redirected to the list of applications again and now be able to see the newly imported Applications. Now you can use them in other screens as well:

Another thing I would like to mention about the Admin – Applications tab. From here you can also completely remove or replace a single application from the database including all references. To see the list of all references, click on the name of the application (which is actually a link). To delete or update click the appropriate icons.

I really appreciate all the feedback. Just get back to me if you need to have a specific topic covered in more detail.

This How To is part of a series showing different features of the Web FrontEnd. If you got something useful out of this one, please also have a look on the others published so far:

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

- How To restrict access to the Deployment Database

MDT Web FrontEnd – a Bugfix, a 64 Bit Version and some troubleshooting help

maikkoster — Thu, 04 Mar 2010 20:44:00 GMT

First I would like to thank you all for your feedback so far. Almost 130 downloads within 3 days is quite impressive for such a solution.

And although just released it was necessary to already patch a small bug. Cleaning up the code close before publishing the first version created a small bug that will cause an error on the access role evaluation. Sadly this affects all non-admin users configured in the frontend so it’s highly recommended to implement this patch. Luckily it’s enough to replace a single dll (MaikKoster.MDT.MVC.dll) in the bin folder of the FrontEnd. Find the download on CodePlex. It brings the FrontEnd to version 1.0.1.

Additionally a second download has been made available. It turned out that it was necessary to create a specific version for 64 Bit systems due to some libraries used for database access that need a special 64 Bit version.

Some general recommendations on Troubleshooting

- Make sure you have the .Net Framework 3.5 SP1 installed. Be aware that it needs to be enabled as a “Feature” on Windows Server 2008 R2

- Make sure you have IIS with ASP.Net Support configured

- On IIS 6 you need to configure Wildcard mapping. See the Installation Guide for details.

- Disable anonymous authentication and be sure to enable Windows authentication. It might be disabled on default installations of Windows Server 2008

- Configure a specific account for the IIS application as described in the Documentation. On any problems add this account to the group of local administrators before any further troubleshooting. Permission problems constitute in weird error message not directly targeting to this. If the error does not occur after that you need to spent some time on getting the permissions right. I will add some general recommendations to the Installation Guide.

- If you try to configure the Database connections via the Admin – Configuration tab it might take up to a minute to open this page. This should happen only if you have a Database server configured that can’t be reached at that moment. If it doesn’t show anything at all try to open the page http://localhost/YourFrontEndName/Admin/configure (while replacing YourFrontEndName :-) ). This should show you more information on the error happening. So far in most cases where this issue happened, it was due to disabled Windows authentication.

If more common issues arise I will update this post and also place a copy to the Installation Guide in the Online Documentation.

Sorry for any inconvenience caused and I appreciate all the help I got so far troubleshooting these issues.

MDT Web FrontEnd - How To create custom Lists to select from pre-defined values for a setting

maikkoster — Tue, 02 Mar 2010 09:28:00 GMT

In the Last Post I showed you, how you can easily create a custom Setting in the MDT Database and use it in your custom scripts. In the example shown we added a custom Setting called “CollectionID” to the Database to enable some kind of Pre-staging for computers. With the example you would e.g. be able to pre-stage computer based on their SerialNumber in the MDT Database and then add it on the fly to the appropriate collection on the fly when pxe/cd booting the new computer. Very helpful if your hardware vendor can’t supply you with a valid MAC Address in advance.

But wouldn’t it be nice to not require the User to enter a specific CollectionID? Wouldn’t it be nice to give him a pre-defined list of values he can select from? Let’s see how we can solve this with the MDT Web FrontEnd. A new feature that came with Version 1 is the option to create custom Lists and assign those lists to individual settings.

A List consists of one or several List Entries. Each defined by a Text shown to the User and a Value stored in the Database. Also a list can either allow only a single value to be selected or multiple values.

Let’s start with the single select as this is what we would need for our example (selecting multiple collections doesn’t make much sense in this scenario). OK, we need a new List. Open the MDT Web FrontEnd, click on the Settings and then on the Lists tab. You will see an overview about all the lists configured so far. The FrontEnd comes already with some pre-defined lists. Now click on the Add List button.

First our new List needs a meaningful name. Let’s call it Collections and give it a short description to help others identifying the lists content. Don’t check the Select Multiple. We will see another example for this later in this HowTo. After supplying a new name, click the Save button.

Now we nee to add some Entries to the list. Each Entry consists of the text shown to the User and the value stored in the Database. See the following screen for an example.

You can edit these lists at any later time. Removing old entries, adding new ones and also re-order them.

OK, next step. We now need to assign this list to our Setting. In the last post we used a category called Helpdesk Settings for this. Let’s update this category. Click on the Settings tab and then on the Categories tab. Now click the edit Icon of our Helpdesk Settings category.

As we can’t edit an existing setting, we need to remove the setting first and then we re-add it using the new List (Yes, it’s on my ToDo list for the next release)

After saving all our changes are effective immediately. Let’s see how this looks like to our Helpdesk Users. For demonstration purposes I added the CollectionID setting again to a different Category so that you can see that the value stored in the Database is still the collection id itself. (It’s configured as ReadOnly so won’t disturb anything)

OK, but what about Multiple values?

A good example for this is the setting KeyboardLocale. This setting defines the default keyboard layout installed on Windows XP Systems. And it can take more than one value. Let’s create a custom list to let our Helpdesk users pick the appropriate values. We open the lists and add a new list as described earlier. But this time check the "Select Multiple” checkbox. Now add a couple of valid entries to the list. The example below is showing the necessary settings for German (Germany), English (US), English (UK), French (France) and Norwegian (Norway - Nynorsk) taken from Locale IDs, Input Locales, and Language Collections for Windows XP and Windows Server 2003. Finding the appropriate values is actually often the hardest part so your co-workers will be very happy to not spent their time on this if you figured it out already ;-)

Now you can use this List again to assign it to a setting as described already. Let’s have a look on how it would look like for our Helpdesk Users when editing the settings of a computer

the Demo Category contains again a readonly copy of this setting to see how it is stored in the database. All entries from the list can be chosen by the dropdown list. All values are shown but only the ones still available can be clicked. The chosen values can be re-ordered by Drag&Drop and the order will also be reflected by the order stored in the database.

As you can see another useful feature for the Web FrontEnd making the daily handling for you and your co-workers a lot easier. For more information about other topics have a look on the Documentation on Codeplex. If you aren’t using the FrontEnd yet, just download it from Codeplex now and follow the Installation Guide. It will take you less than 10 minutes and you will already be able to configure your first values no matter if you are using the MDT Database already or just going to create it now.

This How To is part of a series showing different features of the Web FrontEnd. If you got something useful out of this one, please also have a look on the others published so far:

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

- How To restrict access to the Deployment Database

Version 1.0 of the MDT Web FrontEnd released

maikkoster — Mon, 01 Mar 2010 13:17:17 GMT

Finally it’s done!

I’m very happy to announce the release of version 1.0 of the MDT Web FrontEnd. It took a bit longer than expected since the last Beta from November 2009 but a lot of nice things needed to be added.

But first, what is the MDT Web FrontEnd?

The MDT Web FrontEnd is a web based alternative for the MDT configuration database. It is 100% compatible to current MDT 2008, MDT 2008 Update 1 and MDT 2010 database installations running on SQL 2005 or 2008. Optionally (and recommended) it is possible to extend existing databases to add a lot of new useful features while still maintaining full compatibility to the original MDT Deployment Workbench.

Let’s have a quick overview about the features (bold ones have been added after Beta 2)

Role-based security Model
customized Groups of Settings including Custom Settings
create custom settings
custom Lists to choose from predefined values (single or multiple items)
searching for Locations / MakeModels / Computers / Roles
input validation for common fields (MAC, UUID, Gateway, …)
browsing for Packages directly on a SCCM Server
select multiple packages from SCCM at the same time
Drag&Drop reordering of Applications, Packages, and Roles
Editing/Deleting of all Instances of a specific Application, Package, or Administrator
List all references for a specific Application, Package, Administrator
Import Applications.xml file from the MDT Workbench to easily select applications
manage PackageMappings/RoleMappings
configure the FrontEnd directly from the browser (No need to use IIS)
create and upgrade MDT Databases directly from the FrontEnd

The main purpose is to ease the database handling. Using this Web FrontEnd you can easily configure what a User can see and edit. Think of giving local Site Admins access to their Site(s) only, or enabling the Helpdesk staff to manage all computers while not messing around with your Role configuration. Additionally reduce the amount of available settings to the ones they really need. Create additional custom settings specific for your environment and combine them into some customized views. Create custom lists so that Users can pick from different values to avoid errors by typos. You don’t want to give all your IT Users full access to the MDT database and install the full Deployment workbench on all their computers? You don’t want to overwhelm them with 215+ settings? Then give the MDT Web FrontEnd a try.

Find the download on Codeplex with a (still growing) online documentation. It includes a detailed Installation Guide for new installations and also upgrades from current Beta 2 users. Also have a look on some HowTos published already on this blog. Expect a couple more during the next few weeks getting into more details of some new features.

A special Thank You goes to Jason Scheffelmaer, who has been testing this FrontEnd since the very early versions helping me to get (hopefully) most of the bugs out of it. Also thanks to all the people already using this FrontEnd in their Test and Production environments and for all the feedback I got so far and that haven’t been mentioned here. Not all ideas and requests made it into this version but be sure that this won’t be the last one. If you would like to participate, please get in contact to me. It would be really great to get some support on extending the current documentation and quite obvious I also need help on the optical part ;-). If you are using the FrontEnd in your environment and found a good way to solve some common issues with it, just blog about it to help others solving their issues or to give them new ideas on how to ease certain parts. This year will probably be stamped by a lot of large upgrades from XP/Vista to Windows 7. So having real-world experience available is a key to success. And I hope (actually I’m pretty sure) the MDT Web FrontEnd will become a nice piece in your Deployment solution.

As always, I appreciate all your comments and thoughts.

Be aware, the MDT Web FrontEnd is provided “AS IS” without express or implied warranty of any kind. So you use it on your own risk. Be sure to test it before using it in a production environment.

MDT Web FrontEnd – How To handle Custom Settings/Properties

maikkoster — Mon, 01 Feb 2010 17:01:00 GMT

In the last post I showed you how you can create custom Groups of settings, making it possible to give different Users a different amount of available and changeable information. In this post, I will show you some more advanced features of the MDT Web FrontEnd as it is able to handle custom settings the same way as handling the MDT built-in settings.

MDT gives us a lot of possibilities right out of the box. But often you reach a point in your Deployment, where the built-in methods, scripts and properties aren’t enough to do the job. While creating and adding custom scripts isn’t to difficult (have a look on Tim Minters Post about writing custom scripts with mdt 2010 as a reference) handling custom settings can become difficult. But when do you need a custom setting? At least in all cases where you need to store something (other than the default information) that shall be used later during your Deployment. It might be used as a necessary value in your scripts, it might be to specify if a certain task shall run etc.

So how can we create custom settings?

The easiest way is simply defining them in the customsettings.ini. Have a look at this sample:

[Settings] 
Priority=ComputerSpecificSettings,ComputerSpecificRoles, RoleSpecificPackages,Default 
Properties=MyCustomSetting,MyCustomList*

As you know already, the “Priority” tells the Gather process what sections and in what order to parse. The “Properties” line tells the Gather process what custom settings/properties shall be used (Settings and Properties are identical. They are called “Settings” in the database, that’s why I use this synonym in this post). So in this example we created a “MyCustomSetting” which can take almost any single value. And using the “*” at the end we created a List “MyCustomList” that can store a couple different values (like the built-in “Applications” or “Packages” lists).

That’s actually enough to be able to use those new settings in your Task Sequence. You can assign values by something like MyCustomSetting=ABC-%SerialNumber% and use them in your scripts using something like “oProperties(“MyCustomSetting”)…”. Assigning the proper value to your custom setting using different sections is quite easy. But what happens if you have a setting that can have a multitude of different values? What if you don’t want to extend your customsettings.ini even further as it is already hard to read? The next best option is to store this setting in the MDT Deployment Database you probably have configured already. If not I highly recommend setting this up, even in simpler environments. It takes only a couple of minutes to set up but will save you a lot of time as soon as you have changes in the configuration of your Deployment. Please see Tim Minters Post about Understanding the MDT configuration database for a better introduction on why to use it and how to set it up.

Let’s start with the bad things. The MDT 2008 Deployment workbench isn’t able to handle custom settings at all (without changes to the code). MDT 2010 is able to handle custom settings but they need to exist in the database already, meaning you need to configure the setting by hand and it will just add this setting at the very end of the long list of 215+ settings. Could be more user-friendly.

Now to the good things. The MDT Web FrontEnd will help you with this. You can add(!) new custom settings using the FrontEnd and you can add those settings into any of your custom Groups (have a look in the last post about How To configure what a User can see and edit for more information) making them look like and usable as all built-in settings. And this for MDT 2008 and MDT 2010 Databases. But what is a How To without an example?

An Example

As a frequent reader of this Blog you probably have seen already a couple posts about a “Custom Boot Wizard” which will allow you to boot any known and unknown computer and let you choose from a couple of Task Sequences. But what if you want to pre-stage this information about the TaskSequence for certain computers? Exactly, we need a custom setting to store this information. To keep it simple we just want to store the CollectionID of the target collection in this setting. Saying this, how about calling it “CollectionID”? Open the Web FrontEnd and click on Settings. On the first tab that opens click on the “Add Custom Setting” Button:

Type “CollectionID” and click on “Create”

This new custom setting is now available to be used for our deployments. But we now need to give our Users the possibility to enter values. It will not(!) automatically be added to the CustomSettings section as in the Deployment Workbench. But making this available for your Users will take just a couple clicks and keep your views in a state you want to have them. We now just extend the custom Group we have created in the last post. As explained already, we need to add settings to an existing or new Category. In the last example, we created only one Category, so again to keep it simple, we will just add our “CollectionID” to this Category. This will enable all our Helpdesk Users to pre-stage this information per computer. OK, to do this, click on the Categories Tab and then on the Edit Icon of our “Helpdesk Settings”

In the list of available settings you should now be able to choose the new custom setting “CollectionID”. Give it a proper name like “Target Collection ID” and a meaningful Description. Keep the Type as “Text”. Save your changes.

If necessary, re-arrange the settings. Now if a Helpdesk User opens the Settings of an existing or new computer, he will see the following:

These are the settings of the same computer shown already. But now the Helpdesk User would be able to enter a (valid) CollectionID. OK, it would be nicer to show him a list of available ID’s but I need to keep some room for improvement ;-)

So as you can see, handling custom settings with the MDT Web FrontEnd is quite easy.

Integrate it into the Custom Boot Wizard

To finish this post, let’s see how we can integrate this “CollectionID” into the Custom Boot Wizard. Currently if a Computer PXE Boots, a script (ZTIMediaHook.wsf) will check, if there is already a valid OSD Advertisement available for the current computer. If so, it will simply handover to the Task Sequence execution engine. If not, it will show the wizard and let the User sitting in front of the computer choose a Collection to put the computer into. Now we want it to first check if there is an Advertisement available. Then it shall read the “CollectionID” setting for this computer. If it contains a value it shall try to add the computer to this collection. If successful, wait for the advertisement to come available and hand over, if not show the wizard.

OK, first thing we need is the CollectionID. How do we get this? We could use the Gather process to query the View “ComputerSettings” based on the local MAC/UUID, etc. But this might cause problems as the Task Sequence which shall run later has a different priority for the Gather process. It might even be possible that it doesn’t query this computer specific view at all. And most built-in Properties are defined in the “First value wins” way meaning as soon as a property has a value assigned, it won’t be overwritten.

Based on this, we need to be able to query a single setting. Roughly a year ago, I posted something about Set or Get a single Setting from the MDT Database. The mentioned Stored Procedure and Webservice Function is part of the Deployment Webservice so let’s make use of it. We just need to add a couple lines to your SCCM_Bootstrap.ini file to get the necessary values:

[Settings] 
Priority=Default,UpdateComputer,GetCollectionID 
Properties=AssignedSite,MDTID,Type,Setting,CollectionID 


[Default] 
SkipWizard=NO 
AssignedSite=XXX 
Type=C 
Setting=CollectionID


… 

[UpdateComputer] 
WebService=http://YourWebserver/YourWebserviceDir/MDT.asmx/UpdateComputer 
Parameters=SerialNumber,AssetTag,MacAddress,UUID,Description 
SerialNumber=SerialNumber 
AssetTag=AssetTag 
MACAddress=macAddress 
UUID=UUID 
ComputerName=Description 
MDTID=int 


[GetCollectionID] 
WebService=http://YourWebserver/YourWebserviceDir/MDT.asmx/GetSetting 
Parameters=MDTID,Type,Setting 
CollectionID=string

And a minor change in the ZTIMediaHook.wsf file is necessary as we want to skip the wizard if a CollectionID has been pre-staged. Replace

        If Not HasOSDAdvertisement Then 
            ' Show Wizard 
            sCmd = "MSHTA.exe """ & oUtility.ScriptDir & "\Wizard.hta"" /definition:CustomBootWizard.xml" 
            RunAndLog sCmd, true 


            ' Process result from Wizard if requested 
            If oEnvironment.Item("WizardComplete") <> "Y" Then 
                oLogging.CreateEntry "User has canceled the wizard. Exiting!", LogTypeInfo 
                Exit Function 
            End If 
        Else 
            oLogging.CreateEntry "Computer has already an Advertisement. Skipping Wizard.", LogTypeInfo 
            Exit Function            
        End If

with the following snippet:

        If Not HasOSDAdvertisement Then 
            If oEnvironment.Item("CollectionID") = "" Then 
                ' Show Wizard 
                sCmd = "MSHTA.exe """ & oUtility.ScriptDir & "\Wizard.hta"" /definition:CustomBootWizard.xml" 
                RunAndLog sCmd, true 


                ' Process result from Wizard if requested 
                If oEnvironment.Item("WizardComplete") <> "Y" Then 
                    oLogging.CreateEntry "User has canceled the wizard. Exiting!", LogTypeInfo 
                    Exit Function 
                End If 
            Else 
                oLogging.CreateEntry "CollectionID has been pre-staged. Skipping Wizard", LogTypeInfo 
            End If 
        Else 
            oLogging.CreateEntry "Computer has already an Advertisement. Skipping Wizard.", LogTypeInfo 
            Exit Function            
        End If

The example files for the Custom Boot Wizard have been updated with these changes. They just lack the bold “,UpdateComputer,GetCollectionID” part, as it requires that the webservice is working and that you added this custom setting to the database. So on default it will ignore this. To enable this, just add the bold part to the SCCM_Bootstrap.ini.

OK, great. We were able to create a custom Setting and immediately use it in our Custom Boot Wizard. If that isn’t a good start into the new week. Feel free to to contact me with your feedback and comments. Also be sure to get back to this Blog. There are more things coming.

Note: There is a small bug in the current Beta of the MDT Web FrontEnd when adding the mentioned Custom Settings. It will add the custom setting to the Database, but it will not update all Views like “ComputerSettings” (It’s actually an odd behavior of the SQL Server not updating SELECT * …” views and not really a bug in the FrontEnd but we have to deal with it ;-) ). The example showed in this post will work anyway. Find an update for the current Beta Release of the Web FrontEnd on the Download page. It’s basically an Update for an existing Stored Procedure.

The following How Tos have been published so far:

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

- How To restrict access to the Deployment Database

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

maikkoster — Mon, 25 Jan 2010 08:05:00 GMT

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 create custom Lists to select pre-defined values for a setting

- How To restrict access to the Deployment Database

MDT Web FrontEnd – How To restrict access to the Deployment Database

maikkoster — Sun, 17 Jan 2010 16:53:00 GMT

The MDT Deployment Database is a great utility for your Deployments, no matter if you are using it in LTI or ZTI scenarios. Tim Mintner recently wrote an interesting article about what the Database is and why one should use it. If you use the Deployment console to access the database it has (at least) one major drawback, especially in larger Deployments. Out of the box, the console is the only way of accessing and changing the database (beside using the SQL Management Studio and making changes directly to the underlying tables.). But due to it’s “All or Nothing” approach, you have to give everyone who needs to be able to make changes to the database full access to all information. But you might want to restrict, what people are able to see and change. You might want to give the Helpdesk guys only access to the computer information. Or might want to restrict a local Site Administrator to the settings of the site(s) he/she is managing.

This particular problem was one of the main reasons for the development of the MDT Web FrontEnd. It is a web-based FrontEnd, giving you easy and customizable access to the MDT Deployment Database and will work without any changes to the original tables. After the installation (see the Installation Guide for more information) it will behave like the original Deployment console and give everyone who can access the website access to all settings. But it has a built-in security model you can use by extending the original MDT Deployment Database (see Extending the database for more details). It just adds a couple of tables and stored procedures to the database without any changes to the original ones. So it will still be 100% compatible if you use the console to access the database. In this How-To I will now show you the concept on how the security model has been designed and how you can use these features to give your users and colleagues the access they need to do their job, without giving them the possibility to harm anything they shouldn’t even touch.

OK, let’s start.

The Security Concept

Access Roles

The idea is to map the requirements of a specific access scenario into an “Access Role”. Each Access Role defines the access to either one specific type of Identities (Computer, MakeModel, Role or Location), or to all of them. Each Identity Type has certain areas like the Details, Settings, Packages, Administrators, etc. The Access Role now defines the Access Level for each of this different areas. The Access Level is quite simple. It’s either Read-Only, Full Access or no Access at all.

Sounds a bit confusing? No problem. Let’s have a look on an example. We assume we have a couple of Users sitting in the Helpdesk. They regularly prepare new computers or schedule re-images on existing computers. So they shall be able to change some settings for the computer like the Computername, be able to add and remove predefined Roles, add or remove packages to the computer which shall be installed or add local Administrators in case a specific User needs to be a local Administrator. But they shall not be able to access anything besides Computers. So we open the Web FrontEnd and click on the “Admin” Tab and then on the “Access Roles” Tab to see a list of all existing Access Roles. After the installation there will be two pre-defined Access Roles “Default Access All” which will give every User Full Access to everything. That mimics the usage of the console. Looking at the below screenshot you can see the security settings for each Access Role and also a column called “Default”. Default Access Roles will apply to every User who can access the website at all. Typically you have either one Default Access Role for all identities. Or you have one per Identity you want to give access to. Even if possible, you shouldn't`t create several Default Roles for the same Identity. So the first thing you might want to do after a fresh installation of the FrontEnd is creating a new “Default” Access Role which fits to your needs. A “ReadOnly Example” that gives only Read access has also been supplied in the installation.

OK, we click on the “Add Access Role” Button. In the following screen we can now create our new Access Role. We call it “Computer Editors” (Or Helpesk, or whatever suits your needs), as this Role gives Full Access to all Computers only. Also supply a meaningful Description. Now we set the “Type” to “Computer” and set all Access Levels to “Change” (The “Gateways” area makes only sense for an Identity Type of “Location” but that shouldn’t matter for now). We don’t want to make it “Default”. The option “Groups” defines what you can see and change if you click on the Settings Tab of an Identity. But this will be part of an additional How-To. So for now select the Group “MDT 2008 Default” or “MDT 2010 Default” depending on if you are using MDT 2008 or MDT 2010.

Then click on “Create” and the Access Role will have been added to the list of Access Roles.

Access Role Assignments

We have now defined a new Access Role that will give somebody access to all areas of the configuration of a computer. Now we need to configure, what users shall be using this Access Role. Users can have several Access Roles assigned. And one Access Role can be assigned to several Users. An Access Role can either apply for all instances of an Identity Type (e.g. All Computers), or just for specific instances (e.g. Location “A”, “W” and “Z”). Based on this, we have the full flexibility from Full Access for Everyone down to single instance for a specific User only. And everything in between. You could even give each of your Users access to the configuration of his/her computer(s). This would probably be an administrative nightmare to keep up to date, but it’s up to you how to use it (Maybe someone will create a small script handling this assignments during logon of each User ;-) ). But let’s assign our new Access Role to a couple of User from the Helpdesk. In the list of Access Roles you can see an icon for the “Assignments” ( ) . Click on this Icon and you will see the list of all Users this Access Role has been assigned to and for what Instances (Either “All” or the specific instances):

Now you can “Create a new Assignment” using a 2-Step wizard. In the first step, you need to choose the User(s) you want to assign to the Access Role.

the second Step is to choose the Instances this User/these Users shall be assigned to. It’s either “All” for all current and future Instances or any number of current instances. If you need to create different combinations of Users and Instances, you need to run this wizard several times. Click on “Finish” to apply these changes to the database and with immediate effect, the chosen user(s) will be able to access everything you defined before.

Users

As seen before, to be able to assign an Access Role, you need to choose from a list of Users. Users can be added to the database on two ways. First, each User accessing any page of the FrontEnd will be added to the Database for future usage. (if the database hasn’t been extended this will be ignored by the FrontEnd. And NO, currently there is no usage logging integrated). So fastest way might be to ask the User to access the FrontEnd and after that just add the user to all the Access Roles he/she requires. You also might want to add the First and Lastname later to make it easier to identify them later.

The second way is to manually add the User to the Database. To do this click on the “Admin” Tab and then on the “Users” Tab. You will see a list of all Users currently configured in the Database.

From here you can Add new users or Edit/Delete existing ones and even see all the assignments, a specific user has. The most important part to know here is, that the FrontEnd assumes Active Directory authentication and will try to map the “Username” to the Username supplied by the Browser. So use “Domain\Logonname” as the value in Username if you use Active Directory. If you use a different authentication method it still should work, but most probably requires some more configuration. Also this is untested.

Note: All the mentioned configuration can only be done by a User who has been configured as Administrator (All users that have the checkbox “IsAdmin” checked). If you have just set up the FrontEnd, there won’t be any user, so no one would be able to configure the database as there isn’t any Administrator yet. To overcome this issue, the first User accessing any page of the FrontEnd after it has been set up will become an Administrator. All others will still be added to the database, but just as normal users.

I hope this guide gave you some insight on how you could handle different security requirements of your Deployments. The example itself is quite simple but should show you how to set this up yourself. The main recommendation is to first configure your “Default” access, meaning create one (or several if you need different “Defaults” per identity) Default Access Role that configures what everyone who is able to access this FrontEnd shall be able to see and do. This may vary between No Access at all up to Read access to everything or even Full control on some parts. Then identify the different requirements you have. Mostly you can group your users depending on the required access levels. E.g. Helpdesk access to all computers, Site Administrators access to their locations, Role Administrators to manage all Roles, etc. If a User has been assigned to different Access Roles he/she will have the highest access level configured. Meaning “No Access” does not overwrite any other access level currently assigned.

If a user has more permissions effectively as he should have, there typically is a “default” Access Role giving this permission. So try to keep it as simple as possible, but as complex as necessary.

For more information please see Managing enhanced security features from the MDT Web FrontEnd Documentation. If you have any suggestions or feedback, don’t hesitate to write a comment here or on Codeplex, start a discussion or just contact me. The FrontEnd is currently still in Beta, but already very stable. The first Release will be published soon and it’s already used in production in several environment.

The next How To will cover the creation of the before mentioned “Groups”. A quite powerful feature giving you even more flexibility on what you want to show to the User.

The following How Tos have been published so far:

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