Remove-Item

This one is fairly simple – essentially what happens is you may find when you ask Remove-Item to delete a folder structure using the -Recurse  switch that it has a tendency to trip over itself and leave folders behind as they are still marked in use.. by the cmdlet!  To overcome this we can simply setup a Do While loop to check if the folder exists and attempt to remove it (and all contents) continuously until we succeed (usually completes within 2 loops).

Do
{
      Write-Host "Attempting to remove Files Recursively.."
      Start-Sleep -Seconds 1
      Remove-Item $FilesLocation -Recurse -Force -ErrorAction SilentlyContinue
}
While (Test-Path $FilesLocation -ErrorAction SilentlyContinue)

For those unfamiliar, the Do..While construct will attempt an action once, and then check the criteria to see if the action should be repeated.  In this case Test-Path will return true if the path exists and false if it does not.  So if the folder has been deleted, another attempt will be made.  The -ErrorAction SilentlyContinue parameters simply stop the commands from writing out either the error condition we are explicitly handling (files locked in use) or that the path does not exist (which is what we want in this scenario, so lets not raise an error for that state).

Copy-Item

This one has been around the internet a few times already, and in this case the solution was one I came across.  Unfortunately I’m not sure who the original author is, but if anyone knows I’ll gladly accredit it.  Anyway, the issue is that Copy-Item has a slight behavioural quirk; if you try to copy a folder, and the destination folder name already exists, the item(s) to be copied are instead placed inside the pre-existing destination folder, in a subfolder.

The result is that if you tried to copy the contents of c:\foo to c:\bar, and bar already existed you’d wind up with all your files from c:\foo inside the c:\bar\bar folder!

Thankfully, the function below sorts this behaviour out -

Function Copy-Directory
{
       Param(
       [System.String]$Source,
       [System.String]$Destination)
       $Source = $Source -replace '\*$'
       If (Test-Path $Destination)
       {
              Switch -regex ($Source)
              {
                  '\\$' {$Source = "$Source*"; break}
                  '\w$' {$Source = "$Source\*"; break}
                  Default {break}
              }
      }
      Copy-Item $Source $Destination -recurse -force
}

Now you can call Copy-Directory folder1 folder2 and get consistent results – if the destination does not exist, it is created. If the destination does exist, then all files are copied into the pre-existing folder.

The function works by testing if the destination folder already exists, and if it does, modifying the source criteria so that copy-item is instead looking for a wildcard match on the folders contents, rather than the source folder itself.

This post deals with the (relatively simple) task of setting up the virtual network adapter that is normally nearly always provided as an internal/external network on the student machines, specifically the IP settings so that the guest VMs can communicate with the host HyperV server.

Let’s take a look at the script first, and then i’ll walk you through it.  As noted in the first article, I used James O’ Neill’s fantastic HyperV Module to accomplish the HyperV lifting!

The Script

#Setup Internal HyperV Network if it doesn't already exist

If (!(Get-VMSwitch $NetworkName))
{
New-VMInternalSwitch -VirtualSwitchName $NetworkName -Force | Out-Null
}
Else
{
Write-Host "`nVirtual Network '$NetworkName' already exists, Skipping..."
}

#Setup Local Loopback adapter
$vSwitch = Get-WmiObject -Query ('Select * from Win32_PnPEntity where name = "' + $NetworkName +'"')
$Query = "Associators of {$vSwitch} where ResultClass=Win32_NetworkAdapter"
$NicName = (Get-WmiObject -query $Query ).NetConnectionID
Invoke-Expression 'netsh interface ip set address "$NicName" static 192.168.1.150 255.255.255.0'
Write-Host "Server now has IP on internal network of '192.168.1.150'"

The code is fairly self explanatory, but i’ll walk through it anyway.  First we use the HyperV module to determine if there is an Internal network with the given name in $NetworkName already in existence, and if not we create it.  If you haven’t seen it before, Out-Null is a powershell command to send pipeline information into the aether, and is useful when you don’t want a cmdlet writing back objects or text to the console during execution (a lot of people just instead write to a variable they have no intention of using).

This will create a Virtual network card on the host HyperV system, which can be seen in network connections.  The name you set in HyperV for the name of the network will be the PNP device name, as shown below..

We then use that name to associate the PNP device to the network adapter, and then invoke good old netsh to set the adapter for us automatically.

Why use those methods

I realize that the PNP device name is actually a property directly available on the Win32_NetworkAdapter class, so why didn’t I use it?  The short answer is that the NetworkAdapter can have some very odd behaviours sometimes (watch what happens to your MAC address when you disable the network adapter..) and to avoid those issue’s I only used properties of the class I knew I could rely on – namely the NetConnectionId.

I could have also used WMI to set the IP address information, but it’s nowhere near as easy as calling netsh and certainly isn’t accomplished in a single neat line.  There is no harm in doing it using WMI if you so wish (and that will be easier if you were doing complex configuration changes).

Requirements

First thing – you’re going to need access to the SCOM 2007 R2 media to be able to complete this.  As directed by the SCOM Integration pack, install the SCOM 2007 R2 console on your action/runbook servers and your Client/Designer machines.  If you attempt to use the SCOM 2012 console in it’s place you will (in my experience) receive connection errors when attempting to use the IP.

Create Alert object workaround

Secondly – In order to use the Create Alert object the Integration pack will normally deploy a management pack into SCOM automatically the first time it is used.  Unfortunately the SDK for SCOM has changed and the method previously employed no longer works (you will receive an error stating as such when the object attempts to run).  In order to resolve this, you will need to :

1. Have Opalis/Orchestrator raise an alert in a SCOM 2007 environment
2. Export the management pack from the SCOM 2007 environment that has been automatically imported.  Note that as the MP is sealed, you will need to use the Export-ManagementPack powershell command as the GUI will have the export option grayed out.  The management pack is called Opalis Integration Library.Get-ManagementPack | ? {$_.name -match ’Opalis’} | Export-ManagementPack -path c:\Folder\
3. Import the management pack into your SCOM 2012 environment

Following this, you will now be able to use all of the IP objects in both SCOM 2007 and SCOM 2012.

For those without access to SCOM 2007, i’ve attached a copy of the management pack that you can import into your environment.  Note : The management pack is unsealed as it’s been exported from within a SCOM environment.  If you are uncomfortable importing an unsealed MP into your environment, do not do so, and instead utilize the method above to obtain your own (still unsealed) version of the MP.

Link to Opalis.Integration.Library.zip

Penned by an all-star cast of Microsoft Evangelists and community MVPs, System Center Opalis Integration Server 6.3 Unleashed is a dedicated resource for all things Opalis.  The book is published by Sams, and is available in physical (paperback) and Kindle editions.

Review

For those looking for a thorough and in-depth resource on Opalis Integration Server, this is definitely it.  The book starts out discussing the history and concepts of Opalis integration server, introducing the product to new users and relating users of previous versions to the current product with ease.

The book then goes on to discuss the Architectural design, installation, implementation and best practises when setting up Opalis in your environment, complete with design discussions and important questions that you should consider before touching the installer binaries.

Key foundation objects and common/advanced tasks are covered, always with examples, including Data Manipulation, Data Persistence, Scheduling, calling external systems error control and more.  The book is not afraid to point to community Integration packs to ensure that you can get the most out of your environment, and I’d be surprised if you’ve heard of them all.

The 3rd party integration packs included with the product are then discussed, with object listings and installation requirements.  This is followed by dedicated chapters for integrating Opalis with each System Center product, covering the installation of the IP and then their object uses.  Sample workflows are included with step-by-step construction examples.  It would have been nice if a bit more time had been spent with the 3rd party IPs, but the breadth of products available in this category would have easily turned this 500 page book into a huge hulking tome).

An entire chapter is then dedicated to Data Center scenarios and workflows, with many challenges to/for private cloud tackled and demonstrated.  While the challenges in this chapter are solved primarily to System Center products, you can easily see how they could be resolved with comparable technologies (Swap out System Center Service Manager for your own CMDB and Service desk product, for example).

Finally, the book discusses the Quick Integration Kit, and unlike many other resources I’ve seen out there actually covers the QIK/Opalis SDK.  This chapter is a good compliment to the QIK SDK documentation and if you are interested in IP development is definitely a must read.

The appendices are full of useful links to various online resources, many of which readers will already (or should) be familiar with.

Looking ahead – System Center Orchestrator 2012

The book is very careful with the topic of Orchestrator and does not attempt to muddy the waters – it is firmly an Opalis 6.3 book.  However nearly all the topics discussed and skills learned are directly applicable to Orchestrator and i’d still recommend the book to anyone using scorch as aside from the system requirements and Operators console, everything else is directly transferable (albiet with a slightly different dictionary – Policies are now Runbooks, Objects are now activities, etc).

Summary

In closing, I felt this was a good resource with lots of practical, helpful example workflows.  The subject matter is discussed in-depth and limitations with the product are addressed, with best practise being discussed throughout.  There are unfortunately some editorial errors in the book (in one case a displaced paragraph!) but the technical content remains error free.  This is a book I am glad to own and one I’d recommend to anyone interested in or working with Opalis 6.3 or the upcoming Orchestrator 2012.

For those of you looking for a solid introduction or rounding out of your Opalis knowledge/skills, this is a very good, hands on course.  The ratio of time spent in hands on labs to lecture/discussion is almost 2:1, so for those of you who like getting your hands on the product and learning for yourself, this is a great course.

Many of the powerful foundation objects are covered, with practical examples of the application of each.  The courseware also covers integrating with the entire system center suite, though labs neglect SCCM and SCDPM unless you/the instructor choose to set a challenge lab.  Also discussed (though not to a huge depth, given the courseware requirements and general accessibility) is the production of one’s own Integration Packs using the Quick Integration Kit, including a lab on the QIK CLI.

Finally, for those of you considering Orchestrator this course is completely applicable – all of the knowledge transfers directly across with only a few modifications (namely terminology, system requirements, and the Operations Console, the latter of which is only discussed but not featured in the courseware/labs).  A good instructor will point out these where appropriate so that you are ready to go when Orchestrator goes RTM (currently Orchestrator 2012 is in public beta).

In closing, this is one of the higher rated MOC in recent times, and it’s clear to see why.  I wouldn’t recommend taking every MOC, but I’d definitely recommend this one.

Course 50507A: Designing IT Process Automation with Opalis Integration Server

In powershell this is a fairly trivial task, as depending on the script language you wish to embed you can either use a script block or a Here-String.  A Here-String is a powershell construct you can use to declare a string where all formatting, special characters are ignored.  This includes carriage returns, so you can easily create multiline strings.  You can also use a variant to suspend string substitution.  The block below shows an example..

$Script = @"
'This is the first line of a 'String'' without any matching "quote` marks.
'This is the second line of the string with a         tab in it
option explicit
Dim someVar, otherVar
'Do some work here
WScript.Echo "Some output"
WScript.Quit

"@
$Script | Set-Content '.\VBScript.vbs'

Unfortunately wordpresses code block doesn’t recognise the here-string, but i assure you it works! Note that because tabs are captured inside the here-string, if you choose to indent the string, the tabs will be captured into the middle of your string.  Note that if you use speechmarks string substitution will still take place, so if you want to use $ in your here-string, use apostrophes instead ( @’ this is my string ‘@ )

Once you’ve got your string, all that you have to do is output the string to a file using Set-Content or Add-Content.

If you’re embedding a powershell script, you can instead use a scriptblock.  This is quite nice if you are writing your script inside an IDE like Powershell ISE, PowerGUI or PrimalScript, as now you can have syntax highlighting which hopefully will help reduce the number of errors inside your embedded script.  I’ve given an example below..

$Script = {

                  Write-Host "inside scripblock.."

}

$Script | Set-content .\Powershell.ps1

If you want to persist or setup arguments into your embedded script, you can use string replacement with here-strings to modify your script. Just put unique placeholder text into your string (such as ARG1_PLACEHOLDER) and then use pattern matching (or string substitution) to replace this with your value.  See the below example..

$Script = @"
'This is the first line of a 'String'' without any matching "quote` marks.
'This is the second line of the string with a         tab in it
option explicit
Dim someVar, otherVar
someVar = SOMEVAR_VALUE
otherVar = OTHERVAR_VALUE
'Do some work here
WScript.Echo "Some output"
WScript.Quit

"@
$Script = $Script -replace 'SOMEVAR_VALUE', "myValue"
$Script = $Script -replace 'OTHERVAR_VALUE', "myOtherValue"
$Script | Set-Content '.\VBScript.vbs'

Firstly, a note on UAC Elevation and how it works.  Elevation is performed on a per-process basis, at initialisation,  so once a process has been started without administrative rights, the only way to gain those rights is to restart the process or launch a child process and request that it be granted admin rights.

The other important thing to remember, is that when a non-elevated process checks group memberships from a user context that does have admin rights, that user is not returned in the results set.  effectively, to non-elevated processes, no matter what user the process is run with, that user is not in any admin groups.

First up, VBScript.

Option Explicit
Dim App
If WScript.Arguments.length =0 then
  Set App = CreateObject("Shell.Application")
  App.ShellExecute "wscript.exe", Chr(34) & WScript.ScriptFullName & Chr(34) & " uac", "", "runas",1

Else

  'Perform Script Functions...

End If

WScript.Quit()

This is quite an elegant solution, if not the most efficient.  Essentially what the script does is first check to see if the script was started with an argument indicating we’ve run the process as an administrator explicitly.  If that argument is not found, we create a child process with the RunAs verb, and wait for that process to finish before we continue.  Starting the process with the RunAs verb will prompt for confirmation of administrative rights if we are not already in such a context.  The second process here is the WScript engine and our current VBScript’s path.  If our argument is found (in this case, the first argument uac) then rather than launching our child process, we instead carry on with our scripts main workload.

Obviously if your script accepts arguments, make sure you pass the other arguments onto your new process accordingly!  Note that in the above script, if you run the script with UAC off, or if you launch it the first time with admin rights, you won’t see a prompt and the script will just continue (but still create the second process).

Next up, Powershell.  As the Powershell process isn’t quite as  lightweight, we’ll do a check to see if this process is operating with the correct rights before trying to elevate.

     Function Test-CurrentAdminRights
     {
      #Return $True if process has admin rights, otherwise $False
      $user = [System.Security.Principal.WindowsIdentity]::GetCurrent()
      $Role = [System.Security.Principal.WindowsBuiltinRole]::Administrator
      return (New-Object Security.Principal.WindowsPrincipal $User).IsInRole($Role)
     }

The function Test-CurrentAdminRights checks to see if the user that the script (the powershell.exe process) is running under is in the Administrator role.  As I mentioned earlier as the user isn’t marked as being in the administrative groups unless the process is operating as an admin, this will only ever return True if the process is running under an administrative context.

Personally, if the function returns false i’d prefer to throw an exception or message back to the user to ask them to launch the script from an administrative console.  The reason for this is that when we launch a new powershell process it might not have access to the same snappins, variables, current working directory (administrative PS consoles start in C:\Windows\System32), etc.  However, the below function will elevate the current script if you need it to :

Function Invoke-AsAdmin()
{
    Param
         (
    [System.String]$ArgumentString = ""
         )
    $NewProcessInfo = new-object "Diagnostics.ProcessStartInfo"
    $NewProcessInfo.FileName = [System.Diagnostics.Process]::GetCurrentProcess().path    
    $NewProcessInfo.Arguments = "-file " + $MyInvocation.MyCommand.Definition + " $ArgumentString"
    $NewProcessInfo.Verb = "runas"
    $NewProcess = [Diagnostics.Process]::Start($NewProcessInfo)
    $NewProcess.WaitForExit()
}

Just pass in any arguments you need to this function, and it will create the necessary process.

So what does this involve?  Removing the service pack backup files will essentially remove all of the superseded files and libraries that the service pack updated, at the cost of now being unable to remove the service pack (as you cannot roll back to the superseded versions).  The amount of space you will recover can vary but is usually between 1-2gb.  That isn’t a lot for end-user machines, but that can be huge when you are looking at machine images and virtual environments.  Obviously you should thoroughly test your machines / images before committing to such an endeavour. 

There are essentially two ways to complete this process.  If you have access to the Disk Cleanup tool (Windows 7 or Windows Server 2008 R2 with the desktop experience pack installed) you can run that, click on the “Cleanup System Files” button (requires user elevation) and when the tool re-opens select “Service Pack Backup Files”.

If you don’t have Disk Cleanup installed, or are working with an offline WIM image, you are going to need to use DISM.

1. Start an elevated command or Powershell prompt (Run as Administrator)
2. If you are servicing this machine, enter dism /online /cleanup-image /spsuperseded /hidesp to cleanup the online computer.  If you want to cleanup an offline wim image, instead enter dism /image:wimfile.wim /Cleanup-Image / spsuperseded /hidesp.  The /hidesp option will remove SP1 from the “Installed Updates” section of Programs and Features, to ensure that users do not try to uninstall the service pack.  
3. DISM will now remove backup files and superseded components from your machine.  When finished, you should have the below output :

And that’s it, your done!

After quite a bit of experimentation, i found a powershell script cannot delete itself without help from some outside source.  Having the script setup a scheduled task on a timer to delete itself is one option, and Scheduled tasks in powershell is certainly well documented on the internet. 

However, as i already wanted a simple way of students cleaning up their own machines (and telling someone who has never used powershell to run as an admin, set execution policy etc etc isn’t fun) i instead decided to go with a VBScript.  As the Windows Scripting Host copies the entire script into memory and then executes it, this means that VBScripts can not only trigger my cleanup powershell script with the correct arguments, it can then also delete the .ps1 file and itself!  All the student has to do is double click on a shortcut on their desktop.

Here is a sample file that does the job.

Option Explicit
Dim FSO,VbScript,PowershellScript, Shell, Cmd, CurrentDirectory, Answer,
Set Shell  = CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
PowerShellScript = "C:\Training Lab\CleanupScript.ps1"
Answer = MsgBox("Are you sure you want to Remove all lab files?",VBYesNo,"Cleanup Confirm")
If Answer = 6 Then
 'Copy script to current folder
 CurrentDirectory = left(WScript.ScriptFullName,(Len(WScript.ScriptFullName))-(Len(WScript.ScriptName)))
 FSO.GetFile(PowerShellScript).Copy CurrentDirectory & "CleanupScript.ps1", True
 
 'Run Powershell Script
 Cmd = "powershell -executionpolicy RemoteSigned -Command ""& {cd "& CurrentDirectory &"; .\CleanupScript.ps1}"""
 Shell.Run appCmd, 4, True
 'Cleanup Files
 VbScript = Wscript.ScriptFullName
 FSO.DeleteFile CurrentDirectory & "CleanupScript.ps1", True

 FSO.DeleteFile VbScript, True
 WScript.Echo "Cleanup Finished"
Else
    Msgbox "Cleanup Cancelled."
End If
WScript.Quit

This fairly simple script sits on the users desktop and when run, will prompt the user if they would like to cleanup the lab (Just going ahead and doing it doesn’t seem like a wise idea for something so easily launched!)
Once confirmed, we copy the powershell script out of it’s resources folder to the current directory. This may not be neccessary, the reason i had to do it was that i placed the powershell script in a folder it was going to try and delete, so running it from that location wasn’t going to work.

We then build an argument string to run powershell. I’ve used -command rather than -file so that i can change the working directory of powershell. This is becuase my script is going to use the working directory, and when running using an elevated shell i don’t want the path to be c:\windows\system32!  I’ve also specified “-executionpolicy RemoteSigned” so that I don’t have to worry about what the system’s execution policy is currently set to.

Make sure when using the Shell.Run method you specify the bWaitOnReturn argument as True. Otherwise, your VBScript is going to try and delete things whilst they are still in use.  I’ve specified that the powershell window be shown (Mode 4) as the script displays progress reports to the user, but you could hide it using mode 0 if you wished.

Finally, we get the the path to our currently executing vbscript and delete both the powershell script and the VBScript itself.  All done!

Obviously this method has a couple of drawbacks.  Now i have to maintain two script files, and what if i change the name of the powershell script (or the path?).  Additionally, what if my script needs Admin priviledges and UAC mode is enabled?

I’ll address all of those points in later articles in this series.

Naturally Powershell was a good choice for this task as it can accomplish most of the above without breaking a sweat.  Rather than re-invent the wheel, I used James O’ Neill’s fantastic HyperV Module.  All I had to deal with now were some other interesting challenges, namely

• Script Self Deletion
• UAC Elevation
• Having 1 Script create multiple other scripts
• Setting up virtual NICs with correct IP information
• Bugs in remove-item preventing files from being deleted correctly and odd behaviour from Copy-Item when moving directories

Across a series of blog posts, I’ll show how i overcame these problems and created a pretty feature rich script for setting up lab environments.  Enjoy!