Skip navigation

Tag Archives: guide

Now, it’s time to evaluate PowerShell.  As of late, PowerShell has become my preferred method for scripting.  PowerShell is built on top of the .NET framework.  It uses cmd-lets (commandlets) to perform the majority of it’s command line actions.  It’s also fully integrated with WMI and the .NET Framework.  It works off of Objects, which we discussed previously with VBScript.  It shares a lot of similarities to the BASH Shell, but the object based pipe is one of the more powerful features.  Objects in the pipe remain objects through to output.  This is an important element to remember if you are already familiar to the BASH shell and find yourself working in a Windows environment now (such as myself).

There’s a lot of good reading over what PowerShell is, so I’ll go ahead and start with our code and break it down as we’ve done in the past.  We’ll be introducing CASE statements this time around, as well as arguments.  I hope you enjoy it.

 Function Get-PowerShell {

The purpose of this script is to start, stop, or restart services on a single machine or list of machines read from a file.


#Service State Changer Script
#Author: Daniel Belcher

#Syntax:
#    .\set-remoteservice.ps1 stop spooler laptopname

PARAM([string]$STATE,[string]$SERVICE,[string]$TARGET)
$ErrorActionPreference = "silentlycontinue"
Function Set-RemoteService{
SWITCH($STATE){
        "Start"
            {$SET.Start()
                Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Starting`n"}
       "Stop"
            {$SET.Stop()
                Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Stopping`n"}
        "Restart"
            {$SET.Stop()
        Start-Sleep -Seconds 1
             $SET.Start()
                 Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Restarting`n"}
             }

if ($STATE -ne "Start"){if  ($STATE -ne "Stop"){if ($STATE -ne "Restart"){
    Write-Output = "Invalid service state entered`n";Break}}}

                         }
if ($SERVICE -eq "")
    {$SERVICE = Read-Host "Please enter a valid service name"}
    if ($STATE -eq "")
        {$STATE = Read-Host "You need a valid state entry. Start, Stop, or Restart"}
        if ($TARGET -eq "")
            {$TARGET = $ENV:COMPUTERNAME}       
    $FILECHECK = Test-Path $TARGET
        if ($FILECHECK -eq $TRUE){
            $READ = gc $TARGET
                ForEach ($ITEM in $READ)     {
            $PING = gwmi -Query "select * from Win32_PingStatus where Address=’$ITEM’"
    if ($PING.StatusCode -ne 0)
        {Write-Output “$ITEM not found online, or invalid hostname.`n"}
    else
        {$SET = (Get-Service $SERVICE -ComputerName $ITEM)
                        Set-RemoteService
                    Start-Sleep -Seconds 1   
 
$STATUS = (Get-Service $SERVICE.ToUpper() -ComputerName $ITEM.ToUpper()).Status
         Write-Output = "Machine: $ITEM`nService: $SERVICE`nStatus: $STATUS`n"
}
                                }
                            }   
        else
            {$PING = gwmi -Query "select * from Win32_PingStatus where Address=’$TARGET’"
    if ($PING.StatusCode -ne 0)
        {Write-Output "$TARGET not found online, or invalid hostname.";
                            break}
            $SET = (Get-Service $SERVICE -ComputerName $TARGET)
                        Set-RemoteService
                Start-Sleep -Seconds 1  

$STATUS = (Get-Service $SERVICE.ToUpper() -ComputerName $TARGET.ToUpper()).Status
        Write-Output = "Machine: $TARGET`nService: $SERVICE`nStatus: $STATUS`n"
}


Copy and paste the above code and save it as a .ps1 which is the standard file extension for PowerShell scripts.  Now, lets set our execution settings from the PowerShell command line:

Set-ExecutionPolicy unrestricted

You can now execute the script by right-clicking and run with PowerShell, or by launching it from within the shell by navigating to it’s directory and typing it’s name.

Now lets look at our interest areas:

  1. Sequence
  2. Command usage
  3. Output usage
  4. Conditional logic

Sequence:

Sequence inside PowerShell is as expected.  It’s all run inline, and requires everything called to be defined before it’s call.  Looking at the above code you will see that we call Set-RemoteService two times, and we’ve defined it at the beginning of the script.  In VBScript, or in Command, calling a sub, function, or a GOTO statement will find the appropriate section and run that code.  So being aware of how your scripts process instructions is very important to their functionality.

Now for something new, arguments.  Arguments are, more or less, are user defined variables.  They are dynamic, and as such, need to be controlled to some degree.  So a fair amount of the script sequence is spent insuring that the variables passed are useable.  With PowerShell you are capable of defining the variable type.  This gives you incredible control and removes one more potential for unforeseen errors.

PARAM([string]$STATE,[string]$SERVICE,[string]$TARGET)

As you can see, with the PARAM statement we are opening 3 variables for input.  They are $STATE, $SERVICE, $TARGET.  We are also insuring whatever is entered is a string value.  So that leaves us with 2 issues.  The user needs to enter something, and it needs to be useable.  We will discuss this more in our conditional logic.

Command usage:

As we discussed at the beginning, PowerShell uses cmd-lets for the majority of it’s work.  It also allows you to call WMI and .NET methods and functions.  So similarly to to VBScript we can instantiate them for additional functionality.  The possibilities are plain astounding, and well beyond scope for this blog post.

Output usage:

Same as with our previous entries, all the work done is aimed at getting an appropriate output.  As such, capturing, reading, and modifying the output of all our commands is important.  How PowerShell does this, is similar to both VBScript and BASH.  You can pipe for output as input for other commands as well allowing for some very elegant one liner solutions.

Since PowerShell keeps everything in the pipe an object, your variables become immensely powerful since they are more than just stored returns from commands, but instead stored objects with invoke able methods, or property lookup, etc.  Lets evaluate how this works quickly:

$SET = (Get-Service $SERVICE -ComputerName $TARGET)

Here we are using a Get-Service Cmd-Let to grab a specific service, on a specific machine.  Now the variable service we are grabbing will have certain native METHODS and PROPERTIES we can leverage to either invoke or pull data.  What we need to understand is that the $SET variable is now an Object, not a Value.

$SET.Start()

Start and Stop are two methods belonging to Win32_Service objects.  So what we are doing here is saying essentially:

$SERVICE object, Invoke Method Start

So everything you see at the above link is now callable, or retrievable through this variable.  Pretty cool huh?  One thing of note, if you invoke a method that changes the state of an object, it’s properties will not be refreshed until it is called again.  You will notice in the code I declare a $STATUS variable.

$STATUS = (Get-Service $SERVICE.ToUpper() -ComputerName $TARGET.ToUpper()).Status

Because the state is changed, the property Status is changed.  Hence I couldn’t just recycle $SET with the $SET.Status.  The object needs to be refreshed. (Don’t be confused by the .ToUpper(), these are just native PowerShell methods for string management.  In this case UpperCase)

Now the $STATUS variable could just be considered a value.  Since it is in fact a capture of the property value.  Starting to make better sense now?

I don’t really utilize any direct error handling inside this script outside of the $erroractionpreference value.

$ErrorActionPreference = "silentlycontinue"

This just means if I hit an error, move on to the next statement, and do so without any visible output to the user.

Conditional logic:

We’ve discussed if statements before, and as promised, I offer you a practical case statement:

SWITCH($STATE){
"Start"
{$SET.Start()
Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Starting"}
"Stop"
{$SET.Stop()
Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Stopping"}
"Restart"
{$SET.Stop()
Start-Sleep -Seconds 1
$SET.Start()
Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Restarting"}
}

The syntax says switch, but the methodology is the same.  All that is happening is we are saying if $STATE = “Start” or “Stop” or “Restart” do this.  Either 3 separate if statements, or 1 case statement.  Fairly efficient manner for handling complex conditions that hinge around one variable.

So what does this PowerShell script do?

It begins by declaring 3 variables that are to be string values.

Then it tells the shell to remain silent and continue on errors.

Next it builds a function to be reused through the remainder of the script

Function Set-RemoteService{

This is where our case statement is built and stored.  We also have an additional conditional statement in there to insure that one of the 3 pre-defined strings were typed correctly.  Now we perform an if statement to determine that the variables were defined at execution, if not then we prompt the user for input.  If $TARGET is empty we simply define it as $ENV:COMPUTERNAME, which is equivalent to LOCALHOST (just a bit more elegant).

Now it performs a quick check to determine if the $TARGET passed was a file or simply a name.  If it was a file, the file is opened and assigned to the $READ variable where a for each statement is run against it.

A $PING test is done using a WQL to determine if the machine is online, or if the name is even valid.  (the reason we do this, is that it’s increasingly faster to ping for response than to wait for a timeout to occur on a RPC request).

If the machine successfully pings it moves on to declare the $SET variable object for use in the Set-RemoteService function.  Then it executes the function, then a 1 second pause, and then builds an object property variable that is used in a console message to the user notifying them the state of the service after the action.

If it wasn’t a file, it does the same thing without a ForEach statement.

}


So you want a little more?

I’m going to quickly show you how you can integrate this script, into a profile function.  It’s exceptionally easy, and I recommend it for scripts you’ve built that you find invaluable for day to day use.

Here goes the modified code:

Function Set-RemoteService {
PARAM([string]$STATE,[string]$SERVICE,[string]$TARGET)
$ErrorActionPreference = "silentlycontinue"
Function SRS{
SWITCH($STATE){
                       "Start"
                           {$SET.Start()
                                  Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Starting`n"}
                       "Stop"
                           {$SET.Stop()
                                  Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Stopping`n"}
                       "Restart"
                           {$SET.Stop()
                     Start-Sleep -Seconds 1
                            $SET.Start()
                                  Write-Output "`nService: $($SERVICE.ToUpper()) `nStatus: Restarting`n"}
                           }

if ($STATE -ne "Start"){if ($STATE -ne "Stop"){if ($STATE -ne "Restart"){
      Write-Output = "Invalid service state entered`n";Break}}}

                          }
if ($SERVICE -eq "")
    {$SERVICE = Read-Host "Please enter a valid service name"}
    if ($STATE -eq "")
        {$STATE = Read-Host "You need a valid state entry. Start, Stop, or Restart"}
       if ($TARGET -eq "")
           {$TARGET = $ENV:COMPUTERNAME
      $FILECHECK = Test-Path $TARGET
             if ($FILECHECK -eq $TRUE){
                 $READ = gc $TARGET
                           ForEach ($ITEM in $READ) {
           $PING = gwmi -Query "select * from Win32_PingStatus where Address=’$ITEM’"
    if ($PING.StatusCode -ne 0)
       {Write-Output “$ITEM not found online, or invalid hostname.`n"}
   else
       {$SET = (Get-Service $SERVICE -ComputerName $ITEM)
                              SRS
                          Start-Sleep -Seconds 1
$STATUS = (Get-Service $SERVICE.ToUpper() -ComputerName $ITEM.ToUpper()).Status
             Write-Output = "Machine: $ITEM`nService: $SERVICE`nStatus: $STATUS`n"
}
                                                       }
                                               }
             else
                   {$PING = gwmi -Query "select * from Win32_PingStatus where Address=’$TARGET’"
         if ($PING.StatusCode -ne 0)
              {Write-Output "$TARGET not found online, or invalid hostname.";
                                                  break}
                    $SET = (Get-Service $SERVICE -ComputerName $TARGET)
                                   SRS
                        Start-Sleep -Seconds 1

$STATUS = (Get-Service $SERVICE.ToUpper() -ComputerName $TARGET.ToUpper()).Status
             Write-Output = "Machine: $TARGET`nService: $SERVICE`nStatus: $STATUS`n"
}

}

We’ve enclosed the entire thing into a Function statement now, and redefined the internal function.  The reason for this was, well, I prefer to stick with cmd-let naming patterns.  I’d rather call set-remoteservice at the command line.

Now, we need to build our profile, from inside PowerShell, at the command line type:

notepad.exe $PROFILE

Now paste the above code and save it.  If you are inside ISE press F5 to run the script and update your profile, or if you are in the standard shell type:

powershell

This will start a new shell instance inside your previous shell with the updated profile.

Be mindful, PowerShell and PowerShell ISE have two separate profiles.  So if you perform this in ISE the standard shell won’t receive the update and vice versa.


That does it for my stick to the script series.  I hope you’ve learned a lot regarding scripts through this and it’s shed some light onto what scripting is and de-mystified it for you.

I will continue to post scripts for various things over time, as well as neat tricks as I learn them so I wouldn’t say this is truly the end. 

Editors:

If you intend to do a lot of scripting, I recommend you grab yourself a steady editor.  Preferably one with configurable highlighters.  Below are a list of a few free and premium editors I recommend.  I’ll start with the freebies:

  • Context – A nice, windows based, free editor (my usual windows editor). Configurable highlighters, comparison tool, and configurable execution keys.  All the basic needs of a script writer.  Minus integrated libraries.  I believe development has all but stopped since 09, so this might not be the best editor to stick to.
  • Emacs – Extremely powerful development environment built for OSS, but with Windows versions.  This is more than a simple editor, it’s a Swiss army knife.  It will require a bit of a learning curve to begin using it but is worth it in the end.
  • VIM – My preferred editor in Linux, switchable modes, highlighters, line numbers, split views, compares, command line style editing.  Like emacs, it’s extremely powerful, and has a bit of a learning curve.  I prefer VIM, but Emacs is far more extensible, just fyi.
  • NotePad++ – A really nice OSS editor for Windows.  I should probably start using this over Context, but I’ve already spent so much time with Context configuring it, I’ve become extremely comfortable with it.  I’d recommend this editor to any novice windows scripter.
  • PowerGUI – Both a free, and paid edition.  I recommend this editor for PowerShell whole heartedly because of it’s syntax and object recognition tools.  If you are going to do a lot of work with PowerShell, I recommend using this editor for it.
  • PSEdit – Included with the PowerShell ISE.  It’s the standard PowerShell editor.

Premium:

If you are interested in learning more:

Stick to the Script Parts 1 – 4:

  1. Stick to the Script…
  2. Stick to the script #!/BIN/BASH…
  3. Stick to the script CreateObject(“Wscript.Shell”)…
  4. Stick to the Script PS C:\> PowerShell …

Advertisements

So in the world of SCCM there are tons of moving parts and components.  I want to take some time to focus on some common issues with client installation and communication issues, as well as a couple of tools that make troubleshooting infinitely easier.


Tools

First up I want to list 3 of the primary tools I use for client side troubleshooting.

  1. Trace32 Log Reader
  2. SCCM Client Center
  3. JSandys CM Startup Script

Now the first item on that list, trace32 is by far the most valuable tool to the SCCM administrator outside of the console itself, perhaps even more so than the console.  It allows filtering, highlighting, real time updates, and just generally makes the logs readable.

SCCM Client Center, this tool attaches to the cm WMI Namespace and allows for nearly full control of the client on the target machine.  In terms of remediation, or even testing, there is no reason this tool shouldn’t be installed.

Config Manager Startup Script by Jason Sandys.  This script is easily configured for implementation and has fairly rich logging power for a vbscript, it’s also lighter weight than some of the other health scripts.  I highly recommend using this for maintaining client integrity, as well as offering an installer tool for the CM agent by secondary or third parties.


The Client

First, lets start with identifying the clients existence on the local machine.

Here’s where to look:

  • Control Panel > Configuration Manager (this is one of the quickest methods)
  • Task Manager (ctrl+shift+esc) > Processes > CcmExec.exe
  • Task Manager > Services > CcmExec
  • Control Panel > Admin Tools > Services > SMS Agent Host
  • c:\windows\system32\ccm (32bit)
  • c:\windows\syswow64\ccm (64bit)
  • HKLM\SOFTWARE\Microsoft\SMS\Mobile Client\Product Version (32bit)
  • HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Product Version (64bit)

This is a list of the primary locations to check for the presence of the client, it’s also useful for finding methods to script around identifying them.

 

The Client’s Jobs

Now lets discuss what the client does.  First lets recognize that the client is just a dictator for the most case, it tells multiple windows services what to do to complete specific tasks.  Until we need to break down what services do things specifically lets just treat the client as the primary initiator.

  • Policy updates and application
  • Manage downloads
  • System scans
  • Inventory reports

The client and server relationship relies heavily on BITS, Admin shares, RPC (at least for installation), WMI, AD, and WUA.

The client will regularly talk to the server, telling it about any changes it’s had since it’s last conversation, by way of xml.  It will also ask the server what it should be doing differently, to which the server sends the client it’s latest policy.  The client will review that policy then act, or do nothing depending on if there are any actionable changes.

Actionable changes could be installation of software, OS, OS configuration changes, even changes in the frequency of their conversations.  These exchanges of course are called policy updates, and I believe by default they are set to 90 minutes (no real reason to change it either).


Client Installation

There are multiple ways to install the SCCM client, and in a lot of ways, that method will vary depending on your environment.  I will stick to the basics and explain the process if done by server initiated push.  I will also discuss what is required.

First the server begins by initiating a PUSH, using local admin rights, it will copy down the CCMSETUP.EXE file to either c:\windows\ccmsetup or c:\windows\system32\ccmsetup

A service named CcmSetup is made and it begins transferring the client contents to the local machine and finalizing installation and cleanup of the directory.

A log of the transaction is left in the ccmsetup folder named ccmsetup.log

Once this process is complete, the client will perform it’s first policy update and make it’s active client existence known to it’s respective primary server.

 

So what if installation fails?

This isn’t a perfect world.  If you are pushing into an existing environment, things may have accidentally found there way out of standards and or flat broken.

Lets discuss what is required on a local PC for a successful install:

  • Resolvable hostname (proper DNS entry)
  • Service account with local admin rights
  • RPC access to OS components (such as registry)
  • Admin$ shares
  • WUA (Windows Update Agent)

Instead of explaining exactly why for each of these, lets explain how to resolve potential problems with each.  I also want to treat this as an all inclusive troubleshooting guide for the client, so I won’t limit things to just install failures.  Truthfully, if any of these breaks after installation, the client will most likely not function as intended.

Improper DNS entry:

From the local machine there is little you can do to resolve this problem.  Two methods that could resolve the problem are:

ipconfig /registerdns

This will attempt to update the DNS records for all adapters of the local machine.

ipconfig /flushdns

This will dump all resolver cache data on the local machine. (long shot, but I’ve seen this clear up client DNS conflicts from the push)

Any additional resolution would need to be done by the Domain Admin on the DNS server with the improper pointer references.

Service Account with local admin rights:

This is a very simple solution.  Add the appropriate service account to the local admins group on the client PC.  For Installation and operation, this account needs to be set for the client to perform it’s jobs.

RPC Access:

This one can have you scratching your head at times, but a majority of the times it’s tied to a firewall.  Make sure that local firewalls have exceptions built in for the SCCM server.  When in doubt, disable the firewall software to verify if it’s the culprit or not.

Also ensure that the RPC (RpcSs) and RPC Endpoint Mapper (RpcEptMapper) services are Started.

Some of these changes may require a restart before taking effect so  be aware of that while troubleshooting RPC denials.  It’s also worth mentioning there are a multitude of applications that could disrupt this functionality, so be sure to thoroughly investigate the machine for potential culprits.

Admin$ Shares:

First off, the service Workstation (LanManWorkstation) is responsible for these shares, as well as all SMB protocols on the local machine.  If it’s disabled, you will not have these shares.

One of the most direct methods for enabling admin shares is in:

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareWks, 1

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareServer, 1

Then restart the PC. 

Be aware this setting can be viewed as a security risk, and with that being said, some security software may actively disable them.  So treat your evaluation similarly to your RPC troubleshooting.

WUA Disabled:

The Windows Update service being disabled is a fairly simple solution provided there isn’t a GPO forcing it.  You can either enable and set the Windows Update service to Automatic (wuauserv).  Inside the control panel under Windows Update or Automatic updates set it to automatic.

WUA is responsible for system scans, patching, software delivery, essentially a vast majority of the clients functionality.  It is imperative that WUA is enabled.


Logs to Read, and Policy Updates

For the official list of log files, go here.

(http://technet.microsoft.com/en-us/library/bb693897.aspx)

 

I’m going to touch on the more immediate logs for troubleshooting the following issues.

  • Health
  • Policy
  • Connectivity
  • Licenses
  • Installs

Health:

CcmExec.Log, this log is one of the first stops for suspected bad installs.

ClientLocation.log, this log is a good place to verify that client has a healthy install with a site server.

StatusAgent.log, status messages for client components.  Also useful for connectivity issues.

Policy:

PolicyAgent.log, this holds policy request information, very helpful when pulling policy.

PolicyEvaluator.log, this log lets us know know if we are having issues applying policies.

Connectivity:

InternetProxy.log, if you are using unprotected DPs, this is the log to check.

Mpcontrol.log, logs record the state of the management point

LocationServices.log, attempted connectivity to MPs and DPs

Licenses:

Hman.log, if clients aren’t registering this is worth looking into.

Installs:

Ccmsetup.log, client installation happenings are recorded in this log.

Client.msi.log, output from the installer.


That concludes the overview of SCCM client installation and troubleshooting.  Happy problem solving.  For additional information on the client and troubleshooting check MSDN:

http://technet.microsoft.com/en-us/library/bb693982.aspx

and be sure to get involved with

http://www.myitforum.com/absolutenm/PPLSearch.aspx

 


Today we are going to examine VBScript. Now, a bit of fair warning before we start on this.  This scripting language is a departure from our standard shell scripting.  VBScript is an automation scripting language for the Windows Script Host (WSH)/Internet Explorer (IE)/Internet Information Services (IIS), in short, this is the primary Windows scripting language.

Not to get too carried away on the subject, but this language uses a Component Object Model that allows direct (or indirect) action on just about every object within the windows environment and does so natively via the windows script host interpreter ((which is extensible) (wscript.exe or cscript.exe)).  There are nuances to that statement, and I encourage you to investigate it more thoroughly, however I’m going to jump right into some of the basics of using this language, then discuss the code below as we’ve done in the previous 2 posts.

First off, what is a component object model?  Put as simply as possible, they are exposed objects that you can manipulate in the environment by invoking their methods and properties.  This scripting language brings you dangerously close to windows development at times, but at it’s heart, it’s still very much a script.  Controlling environment objects and properties, performing sequenced tasks, and no compile.

Now, I’m going to introduce 4 new things with this script, I will name them now and explain them after we’ve reviewed the code:

Arrays

WMI

Subroutines & Functions (They can be the same, but in WSH they are different)

Loops

Function VBscript (blog)

The overall activity of this script is the same as our drivemounter batch script we made.  Lets take a look at the code.


‘||========================================||
‘||Author Daniel Belcher                   ||
‘||Function drivemounter                   ||
‘||Date 5/4/2011                           ||
‘||========================================||
‘|Objects, Variables, and Arrays ***********
‘\==========================================/
‘|Set number of items in array             ‘|
‘|Example: 3 drives would be (3,1) and 3   ‘|

Dim ArrDrive(6,1)                          ‘|
DriveCount = 7                             ‘|
’|Define the Array to read                 ‘|
    arrDrive(0,0) = "h:"                   ‘|
    arrDrive(0,1) = “\\uncpath\1”          ‘|
    arrDrive(1,0) = "i:"                  
‘|
    arrDrive(1,1) = ”\\uncpath\2”          ‘|
    arrDrive(2,0) = "j:"                   ‘|
    arrDrive(2,1) = ”\\uncpath\3”          ‘|
    arrDrive(3,0) = "k:"                   ‘|
    arrDrive(3,1) = ”\\uncpath\4”          ‘|
    arrDrive(4,0) = "l:"                  
‘|
    arrDrive(4,1) = ”\\uncpath\5”          ‘|
    arrDrive(5,0) = "m:"                   ‘|
    arrDrive(5,1) = ”\\uncpath\6”         
‘|
    arrDrive(6,0) = "n:"                   ‘|
    arrDrive(6,1) = "\\uncpath\7"          ‘|
‘|Define the Server to Ping for Net Check  ‘|
Dim
strSvr                                 ‘|
    strSvr = "servertoping"               
‘|
‘==========================================================================

Const DEBUGMSG = True    ‘True = Debug Messages, False = No Messages
Dim oWShell
    Set oWShell = CreateObject("WScript.Shell")
Dim oWNet
    Set oWNet = CreateObject("WScript.Network")
Dim Target
    Target = "."
Dim oWMISvc
    Set oWMISvc = GetObject _
("winmgmts:{impersonationLevel=impersonate}!\\"&Target&"\root\cimv2")
Dim oPing
    Set oPing = oWMISvc.ExecQuery _
("Select StatusCode From Win32_PingStatus where Address = ‘"&strSvr&"’")

‘|Main Run =================================================================
DriveMount        ‘Perform Function DriveMount
Report            ‘Perform Function Report
Wscript.Quit(0)   ‘Close Script
‘SubRoutines and Procedures ================================================
Sub Mount(letter,path)
    oWNet.MapNetworkDrive letter,path
End Sub
‘*****************************************************
Sub Umount(letter)
    oWNet.RemoveNetworkDrive letter
End Sub
‘|Functions ================================================================
Function DriveMount
http://msdn.microsoft.com/en-us/library/aa394350(v=vs.85).aspx
    For Each item in oPing
        If IsNull(item.StatusCode) or item.StatusCode<>0 Then
‘**********Domain not reachable, unmount drives in arrDrive
        x = 0
          do until x = DriveCount
             On Error Resume Next
                Umount arrDrive(x,0)
                       If debugmsg then msgbox "Umount"& vbcrlf _
                       &"Drive Letter: "&arrDrive(x,0)& vbcrlf _
                       &     "Error Number: "&Err.Number& vbcrlf _
                       &     "Error: "&Err.Description
              Err.Clear
        x = x + 1
          loop
        else
‘**********Domain exists, mount drives from arrDrive

        x = 0
          do until x = DriveCount
             On Error Resume Next
                Mount arrDrive(x,0), arrDrive(x,1) 
                       If debugmsg then msgbox "Mount"& vbcrlf _
                       &"Drive Letter: "&arrDrive(x,0)& vbcrlf _
                       &     "Error Number: "&Err.Number& vbcrlf _
                       &     "Error: "&Err.Description
              Err.Clear
         x = x + 1
          loop 

        End if
   Next
End Function

‘*****************************************************
Function Report
      If Debugmsg then msgbox "Script completed"
End Function
‘End ======================================================================


Copy and paste the code and save as a .vbs file (unless you have a specific editor, I recommend notepad to insure formatting is properly translated.)

Lets start with our 4 areas of interest we’ve focused on with the previous posts.

  1. Sequence
  2. Command usage
  3. Output usage
  4. Conditional logic

Sequence:

Sequencing and Command usage will be the most interesting topics this time around.  Unless wscript is pointed towards a specific function or sub, it reads everything in line.  This point is rather large when you consider BASH and POWERSHELL and a lot of other script languages which will error out if something is called that hasn’t been previously declared (speaking about functions and subroutines, variables must always be declared before usage).  However, the rule remains that everything is read one after another, or AS the interpreter is directed to read.

As a habit when I write my vbscripts I will almost always write them in this format. Variables, Run sequence, subs, functions.  There is no real reason for this outside of the fact I prefer to immediately see variables and prescribed run order.

Now lets look at our variable declaration and focus on what’s new.  An array, and a multidimensional one at that (more than two columns of data).  An array is an assortment of data stored in memory, think of it like a spreadsheet.  Row 0,1,2,3,4,5,6 and Column 0,1,2,3,4,5,6.  This would be a multidimensional array.  A simple array would be 1 Column (column 0) and however many rows as you wanted.  In this script I declare this array to be limited to 7 rows and 2 columns.  That sounds weird right, cause the declare clearly says (6,1) ?  Remember that 0 counts so 6 = 7 and 1 = 2, but you declare it by the integer value of the last entry.

Dim ArrDrive(6,1)

I then declare my Array entries by defining ArrayName(row,column) = data

arrDrive(0,0) = "h:"          ‘|
arrDrive(0,1) = “\\uncpath\1” ‘|
arrDrive(1,0) = "i:"         
‘|
arrDrive(1,1) = ”\\uncpath\2” ‘|

From here on out when I need to utilize any of these pieces of data I can simply call them using their array name and position.  Another way to think of this is a shared variable name perhaps?

Now lets discuss our run sequence:

‘|Main Run =================================================================
DriveMount      ‘Perform Function DriveMount
Report          ‘Perform Function Report
Wscript.Quit(0) ‘Close Script

This block of code dictates the run order of my script.  The first 2 are Functions I have defined, and the last is a wscript method to insure a clean exit (more on this in command usage).

Sequence is important. For organizations sake, I will take a quick and easy VBScript and build it in this fashion.  For me, and for others, it allows for simpler review and additions to be made to the script that could and will improve it’s functionality.  It’s also far simpler to isolate bad sections of your script and to target a specific function for testing.

Now let’s discuss the iteration statements that are introduced in the DriveMount function.  I will touch on the code more specifically when we break down what the script is doing, but an iteration statement is just a loop that continually performs a task until a certain condition has been met.  That could be reaching a certain number, that could be reaching the end of a file, that could be reaching the end of an array, etc.  In this script (although not how I would naturally do it) I’ve offered 2 concrete examples of vbscript loop statements for your review.

Finally, subroutines and functions.  Similar to labels, identical to the function I showed with BASH.  They are, put succinctly, sections of code that can be called by name to perform a fixed task.  In VBScript specifically a sub routine passes back no data, a function does.  So if I need to perform mathematical operations and reuse it as a variable elsewhere, I’d use a function*.  If I just need to move a file from one location to the next, a sub.  As a safe bet inside of VBScript, declare them all as functions, there is really no benefit I’ve found one way or the other.  I declare them as Sub and Function only to offer them as an example. Syntax for this is:

 Function Name                              Sub Mount                         

        Code to use                             Code to use

End Function                                End Sub

If you wish to use arguments with these functions/subs you would use:

Function Name (arguement1, arguement2, etc)

                Code using arguments provided

End Function

Command Usage:

Unlike our other scripting languages so far, the WSH doesn’t really utilize commands per say.  Command usage is actually called through a COM.  So when you build a vbscript, you spend the first portion of the script defining what COMs will be utilized in the script.  This is all part of my initial variable declaration (DIM statements or Declare Into Memory)

Dim oWNet
    Set oWNet = CreateObject("WScript.Network")

This is essentially creating the callable object or “commandoWNet for me to use moving forward.  What’s actually happening is I am using the WScript object to instantiate (create an instance of) the WshNetwork object for later method or property usage (exposing the object for manipulation).

This is how an object based language works, call the object, use the object, (and ideally) release the object.  When I later use these objects methods I will do so by invoking them.  Syntax comes in to play in these cases.

             oWNet.MapNetworkDrive letter,path

That is the invocation of the WshNetwork MapNetworkDrive method which requires drive letter then path to map.  Hopefully that makes sense, it’s an extra step but allows for some amazing control and it remains rather light weight as it depends on existing objects for it’s control base as opposed to having them already built in.  However that’s not to say there aren’t commands built into the WSH but they are for conditional and iteration statements as well as integer, string, and date functions (w3schools.com has a nice breakdown as well) etc.

Output Usage and Conditional Logic:

For this script the output usage is in reading a ping response, mapping drives, and in exception handling (error catching).  We read the status code from the WMI Win32_PingStatus class object (list of WMI Classes) then use it as our condition.  We then loop through the array and perform the appropriate action while catching and clearing any potential errors.  We also redirect that error output to a popup message if DEBUGMSG Boolean is set to TRUE in our initial variable declaration.

Our conditional logic as stated before is in the form of IF statements.  I will demonstrate case statements in my PowerShell write up.  Case statements look for something (usually a specific string type) and respond in a defined way.  However a case statement is strictly defined where an IF statement is generally this or that, it will make more sense in the future I promise.


So what does this vbscript do?

In this script we open with our declarations.  We define our Array ArrDrive as a 7 row and 2 column array (0 counts, remember though declaration will be the last integer value so in this case: 6,1) and supply it with values.  We set a Boolean for debugging messages and we set our object instance for WScript.Network to oWNet. 

We also start an instance of the WMI Service, and define a WQL that reads the ping status to a targeted server (strSvr) for us (Target=”.” means the local machine, it can be changed for remote PC name, more on wmi scripting).  (WMI is Windows Management Instrumentation, similar to the WSH objects it contains a series of namespaces, classes, methods, and properties to control the windows platform.  Essentially if you can do it on the Windows machine, there is a WMI namespace/class/method involved in it.)

Dim Target
    Target = "."
Dim oWMISvc
    Set oWMISvc = GetObject _
("winmgmts:{impersonationLevel=impersonate}!\\"&Target&"\root\cimv2")
Dim oPing
    Set oPing = oWMISvc.ExecQuery _
("Select StatusCode From Win32_PingStatus where Address = ‘"&strSvr&"’")

Now that we have all that declared we move into our run sequence.  The Function DriveMount is first and it immediately performs a For Each statement through our oPing WQL and grabs the statuscode value and compares it with an IF statement.

For Each item in oPing
         If IsNull(item.StatusCode) or item.StatusCode<>0 Then

If there is no value, or the status code is anything but 0 (0 is a clean exit code, success, that’s what the status code is in its simplest form) then we aren’t in our appropriate network so we will begin a Dismount loop.  If the return value is 0 and is NOT null then we will perform a Mount loop.

Lets stop here for a second so I can explain this loop line for line, first the code sample:

‘**********Domain exists, mount drives from arrDrive

x = 0
  do until x = DriveCount
     On Error Resume Next
        Mount arrDrive(x,0)
, arrDrive(x,1)  
              If debugmsg then msgbox "Mount"& vbcrlf _
              &"Drive Letter: "&arrDrive(x,0)& vbcrlf _
              & "Error Number: "&Err.Number& vbcrlf _
              & "Error: "&Err.Description
     Err.Clear
x = x + 1
   loop

We declare x as 0, we will enumerate this integer value with each pass of our iteration (loop).  Word of warning here, if using this method make doubly sure that you set your enumerate value outside of the loop or it will be re-declared each loop and become an infinite loop.

We do until x = DriveCount, we declared DriveCount as 7 at the start of the script.  This loop will loop 7 times.

On Error Resume Next, we will not let error outputs break our function, we will perform the next in line.

We run the Mount subroutine passing the letter and path arguments which we pull from our arrDrive array.  We use x to select our row (remember we are enumerating x) and select the appropriate column for the data to pass.

Now as an extra step, we check for the DEBUGMSG Boolean, if it’s TRUE, we generate a popup window that tells us what Subroutine is being used, drive letter, error number, and error message. (if the drives are already mounted it WILL error, the error is that the drives are already mounted, so this is helpful if we are chasing something down)

We clear the errors that may or may not have been generated.

Now we take x and we add 1 to it, so 0 becomes 1, 1 becomes 2, 2 becomes 3, etc on each successive pass.

Finally we terminate the statement with loop so that the WSH knows to return to the start of the loop statement.

Easy huh?  There is a lot of power to learning how to use loops and for each statements effectively.

I would normally have just made another for each statement against the array which would read it to the end, but I felt this serves as a great learning opportunity.

At this point our DriveMount function is complete so we move to the next Function in the run sequence which is Report.  Report runs a debugmsg check and tells us the script completed if debugmsg is true.

Now back to our run sequence where we close our script with

Wscript.Quit(0)

This insures an exit code of 0 which is a universal “everything ran great, nothing to see here” output.

End Function

Next up we will be discussing PowerShell.  A very robust shell scripting language for the newer windows platforms (xp sp3+) that utilizes commands, .net, com, wmi, dcom, and the list goes on.  I’ll try to keep it lite.


Now for some bonus material, lets take a look at the Mount loop if I had used a For Each instead of a conditional loop:

x = 0
For Each object in arrDrive
    On Error Resume Next
       Mount arrDrive(x,0), arrDrive(x,1)
            If debugmsg then msgbox "Mount"& vbcrlf _
            &"Drive Letter: "&arrDrive(x,0)& vbcrlf _
            & "Error Number: "&Err.Number& vbcrlf _
            & "Error: "&Err.Description
     Err.Clear
x = x + 1 
Next

You are probably thinking “this looks the same, why is this better?”.

When you perform a conditional loop statement it needs a stop point which is another factor you have to manage.  In this case we had to declare a maximum loop count (our DriveCount variable which was 7).  A for each statement will go through a list till the end and then move on.  You can think of a for each statement as “For Each item in whatever until the end.”

If you have any questions or corrections, please leave a comment and I’ll try and get back with you about it. For an unaltered version of this script to copy and paste, go here.