Writing Scripts

To write scripts, you have to be familiar with the syntax of the language in which you are planning to write the scripts. This is best accomplished by reading a book on the subject. However, you might be able to learn scripting by modifying samples to serve your purpose. Because most programming languages have an English-like syntax, you might be able to discern the meaning of the lines by just reading them if you are comfortable with English. For more information, see the "Learning More" section later in this appendix.


  • As with other SMS tasks, you should test your scripts in a test environment before deploying them in your production environment. This prevents unexpected results from adversely affecting end users.

One approach to writing scripts is to use the following procedure.

A process for writing scripts

  1. Think about what your script must accomplish. For example, it might need to connect to the SMS namespace (in WMI), find a collection that is based on a collection identifier, and change a property on that collection. Make a list or diagram of the flow of the script.

  2. Execute the steps that are required to complete the operation by using the SMS Administrator console or a similar tool. Using Wbemtest.exe or CIM Studio from the WMI software development kit (SDK), view the WMI instances that were created by the operation. Watch for checks that the SMS Administrator console does to ensure that the operation is done successfully. For example, the SMS Administrator console does not allow you to create two collections with the same name. Ensure that the plan that was created in step 1 includes setting and checking all the values that are set and checked when the operation is performed manually.

  3. Try to find a script that is similar to the script that you want to write. Relevant samples can be found in this appendix, the Microsoft Systems Management Server 2003 Software Development Kit, the WMI SDK, and many public Web sites. Even if the examples are not in the scripting language that you are using, they can still provide useful hints as to what you need to do. Copy the most relevant scripting sample that you can find. The script might have little in common with your intended script, but any common elements can help. For example, the script might connect to WMI or even to the SMS namespace. If you can find several scripts that have common elements with your intended script, copy the relevant parts to the new script.

  4. Using Notepad or a similar editing program, remove lines of the copied script that are not similar to what you need. You might change them into comment lines if you suspect that you might need them in the future.

  5. Starting with the first task that the script must accomplish, add or change lines to fit what you outlined in steps 1 and 2. You might start with a script that connects to the SMS namespace and then add lines to find the collection that you need. Do not add lines to modify the collection yet. This helps keep the script simple.

  6. Run the script as it currently exists and correct any reported errors. Read relevant documentation and look at samples to find ideas for what might be wrong. If you still cannot correct the errors, simplify a copy of the script as much as possible while still reproducing the problem. This ensures that you are focusing on the lines that are causing the problem.

  7. If possible, add a line to the script to display the results of the functionality that you added in step 4. For example, you might add a line to display the error status or collection name after you attempted to get the collection. This line is probably just temporary; you might not want it in your final script, but it can help to verify that your script is working properly so far.

  8. Repeat steps 5, 6, and 7 until the script does everything that you outlined in steps 1 and 2.

  9. Thoroughly test the script in your test environment. Verify that the script completely reproduces the changes that you observed in step 2. Test the script with a range of reasonable parameters to ensure that it behaves as expected. Test the script with invalid parameters and any other variations in sequence or environment that might be relevant to ensure that it rejects invalid parameters in a friendly manner and cannot do anything adverse. Have co-workers use the script to see if it works properly. Adjust the script until it safely does exactly what you require.

  10. Test your script in a production environment. Start with a small, less significant site if you can and scale up your testing as you become confident that it is working exactly as you intend.

  11. Put the script into production. This can include ensuring that all relevant details are documented for future reference and that all relevant co-workers and managers are aware of the script that you have implemented.


  • Your scripts manipulate SMS objects rapidly and directly, probably without human supervision. Under these circumstances, your scripts might do things that an SMS administrator would not do. For example, the SMS Administrator console checks for reasonable values (for example, that a collection has a unique name), but your script does not make such a check unless you add code to the script to do so.

For More Information

Did you find this information useful? Please send your suggestions and comments about the documentation to smsdocs@microsoft.com.