Export (0) Print
Expand All

Professor Windows - June 2002

Scripting Your Windows 2000 Network, Part 1
By Yossi Saharon
Reviewed By:
Tal Sarid, Technical Specialist, Microsoft Israel

Introduction

The changing world of IT brings new challenges to IT Professionals that work with Microsoft technologies. Windows 2000 systems, although powerful, can be very complex. As part of the evolution of the Windows family, new and improved wizards have been introduced to the system to empower the user and administrator to do many tasks in an easy and straightforward way, straight from the user interface. To feel the sheer power and speed of the system...to "rule the machine," so to speak, you need to really explore going out into a command console or by automating tasks through powerful, yet simple to understand scripts. Scripting has always been around, especially for the people that come from a UNIX background. Yet today, more than ever, your IT tasks will rely more and more on scripting your Windows 2000 network.

The two-part column series outline why scripting is so important when working with Windows 2000 and beyond, along with some good hands-on samples taken from various network and domain management tasks.

Part 1 aims at providing the necessary background and overview into the world of Scripting, and Part 2 (available in July 2002) will be more practical and contain sample code snippets.

Why Do We Need It?

If you're not a "natural" script-writer, and you have no development experience whatsoever, you can still find it very appealing to start learning scripting due to a variety of reasons.

Here are some of my thoughts why Scripting comes so much handy and useful:

  • When there's no other option. Not everything is exposed in the GUI, and wizards can be helpful yet restricting at the same time. Running to look for a "dev guy" whenever you need that small task that the GUI doesn't provide can become a common scenario in certain organizations.
  • Automation and time-saving. Running bulk operations every certain interval can be very time-consuming. Automation is key for almost every organization that I can think of.
  • Get the right information at the right time and manner. We must control our network in such a way that it provides us what we need, when we need it, and exactly in the format or manner that we need it.
  • Documenting management tasks. In a way, a script is not more than a re-usable document that outlines step-by-step how this management task needs to be done. We can use scripting to re-use the knowledge required for a certain task, understand it, and troubleshoot the process in a step-by-step approach when needed. Go figure what and exactly where something went wrong when a wizard fails on you at 95 percent progress bar.
  • Web applications. Everyone uses web applications. Browser-based applications often use ASP (Active Server Pages), which is essentially nothing more than scripts with a bunch of graphical elements added to them. Learning to script will eventually earn you the knowledge to develop your own custom web applications (e.g. browser-based tools for intranet use).
  • Because it makes us better IT professionals. In the IT industry, a large aspect of your career depends on your versatility and the variety of knowledge fields to which you can contribute.
  • Because some of us simply LOVE it! It's a fact. Some of us just can't get enough of it. It's fun, it's customized, it's challenging and it puts your brain into work a lot more than your daily wizards…

Getting Acquainted with the Different Technologies

There are many technologies associated with scripts, both directly and indirectly. Running a complex batch file can also be considered by some, as a scripting operation, even though it uses only commands that are known to the command shell, rather than explicitly using software interfaces that can be accessed programmatically.

One good link to start with is the Windows Script homepage: http://www.microsoft.com/scripting . From there you can get to information regarding most, if not all, of the main technologies that are used in a scripting environment. There are also some good Microsoft Press books out there on many of the technologies involved, as well as MOCs (Microsoft Official Curriculum) for some of them.

In this column we will focus on the two main and most common technologies: WSH (Windows Scripting Host) and VBScript (Visual Basic Scripting Edition).

WSH is a language-independent scripting host for 32-bit Windows operating systems. Previously, the only native scripting language supported by the Windows operating system was the MS-DOS command language. MS-DOS can be fast and small in footprint, yet it's quite limited compared to VBScript or Jscript. Using ActiveX scripting architecture, users can take advantage of powerful scripting languages such as VBScript and Jscript while MS-DOS command scripts are still supported. Windows Script Host enables scripts to be executed directly on the Windows desktop or command console, without the need to embed those scripts in an HTML document. Scripts can be run directly from the desktop by clicking on a script file, or from the command console. WSH provides a low-memory scripting host that is ideal for non-interactive scripting needs, such as start-up, shutdown, logon and logoff scripting, administrative scripting, and so on. More information on WSH can be found at: http://www.microsoft.com/windows2000/docs/winscrwp.doc .

VBScript is a very useful technology for a wide variety of environments, including Web client scripting in IE (Internet Explorer) and Web server scripting in IIS (Internet Information Services). It's relatively easy to use and learn. Even if you do not know Visual Basic, once you learn VBScript, you are on your way to programming with the whole family of Visual Basic languages. If you already know a little bit of Visual Basic or Visual Basic for Applications (VBA), VBScript will be more than familiar. To start learning more about VBScript, try this tutorial:

http://msdn.microsoft.com/library/en-us/script56/html/vbstutor.asp .

Sample Implementation: Retrieving the Currently Logged-on User's Details

There are many ways to get the currently logged-on user, either by getting the login name from the %USERNAME% system variable or using WinNTSystemInfo, just to name a few. When running in a Windows 2000 domain, a useful way to get any property we need about the currently logged-on user is to use the ADSystemInfo object. The ADSystemInfo object resides in activeds.dll, which comes with the standard installation of ADSI on Windows 2000.

For example, take a look at the following VBScript:

' -Start
' Get Currently Logged-On User details
Set sysinfo = CreateObject("ADSystemInfo")
Set oUser = GetObject("LDAP://" & sysinfo.UserName & "")
msgbox sysinfo.username
msgbox oUser.telephonenumber
wscript.quit
' -End

This script binds to the user object in Active Directory, and displays a message box containing that user's Active Directory path (The object's DN - distinguished name), followed by a message box that displays the user's phone number property in Active Directory. Using this script you can get and set any property you want for that logged-on user. Note that the ADSystemInfo object is intended only for Windows 2000 and above.

Consider this as an easy and simple "appetizer" for what's waiting in Part 2. After understanding what scripting is and what technologies are involved, Part 2 of this two-part column series will go more practically into the various management areas, such as security, managing users and computers. In addition, we'll discuss and get hands-on with more empowering script samples.

Related Links

Windows Script homepage

WSH (Windows Scripting Host)

VBScript Tutorial

TechNet Script Center

For any questions or feedback regarding the content of this column, please write to Microsoft TechNet .

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft