Often the simplest tips are the best ones, so here is one I have been using pretty much ever since I started working with MDT.
When working as part of a team in the same MDT environment, you can often run into issues when various people are modifying the task sequence, or debugging a process that is part of it. My own method to mitigate this issue is to fork the "official" task sequence, creating my own one, in order to separately realise testing or to simply try something out, before feeding changes back into the main task sequence.
The downside to this method is that, by forking the task sequence, the new forked one also appears in the list of task sequences and thus allows somebody to accidentally run it, possibly causing undesired results to their computer (such as formatting it!). Therefore, in order to prevent this situation, I always introduce some simple validation tasks into the task sequence, typically right at the start. These validation steps perform a simple query to check if a computer is "authorised" to run the task sequence or not. My authorisation method is usually based on the MAC address of the computer, but it really can be any value that you like.
The best thing about this tip is it's simplicity. As you can see in the screenshot below, it only consists of two tasks (the Gather task is actually only required if you have not already run a previous Gather task), and a Run Command Line task. You'll notice that the command line is incorrect. This is intentional and not an error, and if MDT attempts to run this command line it will fail the task sequence execution.
Here are the steps I use to implement this:
Notice that the condition is actually a negative. Consequently, when a computer runs the task sequence, this task will only execute if the MAC address of the computer does not match one that is in the list. And because the command line of the task is erroneous, MDT will fail at this point, thus preventing the unknown, or unauthorised, computer from continuing.
When working with MDT and Configuration Manager, you could restrict use of a task sequence by only advertising it to a collection built using direct membership. However, there might be situations where you can't or don't want to use this collection method. This tip works equally well in a ZTI environment if you wish to use it that way, however you might need to add an additional "Use Toolkit Package" task before the Gather step.
Finally, there are other methods to achieve the same result, such as using the CustomSettings.ini file; the reason I do it this way is because its implementation is so quick and simple.
This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK
Daniel Oxley des Deployment Guys vient de publier un article sur la restriction de l’usage d’une
Great post over on The Deployment Guys by Daniel Oxley. Read the full post here. This post was contributed
Is it just me or is the logic you use in this task sequence incorrect. Shouldn't it be "If All conditions are true"? It seems like this would evaluate true even if you were running it on a computer with one of those MAC addresses. As if your MAC address was FC-52-AF-74-CB-61, the second statement would evaluate true and thus run the task.
Restricting Task Sequence Usage is a critical part of our UAT process. Being able to publish a deployment task sequence to our remote sites but limit\restrict who can deploy it has been an important part of controlling the propagation of a new client-end configuration before they have been fully tested. To accomplish this we have a simple script that derives a password from the task sequence Name using some math. The script then prompts for the password and returns a none zero exit code if incorrect... the none zero code kills the task sequence (errors out). Only a few people have another little script that reads in the Tasksequence.xml file from a deployment share and generates the passwords for each of the sequences. This ensures that its completely dynamic and we don't have to worry about emailing TS passwords around whenever we add a new TS for Beta or UAT testing.