One thing I really like about MDT 2010 is the implementation of Search Folders. By this highly flexible solution one can create a complete structure for several different scenarios at the same deployment share and group it for specific requests. It allows to e.g. handle 32 and 64 Bit applications in the same structure but giving a specific Task sequence only “access” to some of the folders.

While this feature gives a great amount of flexibility to the Deployment workbench, the MDT Database is lacking a simple way to achieve similar results. A common problem probably many of you already experienced is handling of 32 and 64 Bit Task Sequences. Having unique steps in each TS handling the specific requirements of each architecture isn’t a problem. But what happens if the packages that shall be installed are defined in the database? Let’s say you have a couple packages defined for a location. How would you be able to identify that some of them must not be installed on 64 or must be installed on 64 only?

Or how can we handle versioning? If you have a task sequence in production you most likely don’t apply any changes immediately to the production TS (at least I hope so ;-) ). So I typically create a duplicate of the existing TS and apply all changes to the duplicate to test them. After testing was successful and all possible problems have been resolved I can redo those changes at the production TS. But what if you need to test certain packages just for this particular TS? You would need to add them as single steps as there is no easy way to configure the database in a way to restrict certain parts to this task sequence only. Or how about Server and Client Deployment? They are completely different and I typically recommend using two different databases for this. But I actually would like to handle this from one single source only.

So what I would like to suggest is a way to handle this problem. But I would also like to start a discussion about if this is a good way of doing this. So let me first explain how I think about it and I will then link to a discussion on CodePlex.

OK, it should be easy to implement and have as less influence on the database itself as possible. If anyhow possible, it should still be compatible to existing MDT implementations. So one way of doing this is adding something like a Tag, you could also call it version or category (while category wouldn’t be a good as the term is used already in the MDT Web FrontEnd for a different purpose). Think about the typical blog. Each post has several tags that allows you to either see a full list of all posts or limit the list by one or several of these tags. If we now add a “Tag” (or “Version”) column to some of the tables in the MDT database, we would be able to limit the queries during deployment time by simply adding one (or several) allowed tags/versions to the task sequence itself (or even get these dynamically at runtime what makes it a bit more complicated but also more powerful). Now you have two general approaches of querying, depending on your needs. Get all “empty” entries including the ones with the configured tag/version, or get only the ones “tagged” the right way. (Or add something like a “All” tag/version to each entry to simulate the first approach).

There are other ways of doing this but I personally think that this is a way with a minimum amount of influence to existing installations and minimum effort to implement and use. But I really would like to hear your comments and tell me what you think about this. Maybe you have a better idea or can help on the implementation. As comments on this Blog are quite restricted I have started a Discussion thread on the CodePlex page of the MDT Web FrontEnd. Find it at Enabling versioning in the MDT Database.

I really appreciate your help and comments.