Arposh Windows System Administration tool 2.0 (AWSA)

Download AWSA 2.0


New in v2.0:
  • Compatibility with Windows servers
  • Many pre-requisities removed
  • Customization of results via XML file
  • Built-in search function
  • View services of remote computers
  • Send messages to computers remotely
  • Context menus
  • Performance has been enhanced greatly
  • Ability to add local administrators

ACSA Requirements:
- Powershell v2 or greater

Features:
  • Connects to currently logged-in domain on startup or domain set in XML file
  • Search for PC - Search Active Directory for computers matching the string in the textbox
  • System Info - Gathers info about PC, user session, make/model, hardware, OS, and networking
  • Local Admins - Enumerates local administrators and allows you to add or remove them
  • Applications - Enumerates installed software and allows you to uninstall
  • Startup Items - Enumerates startup items and allows you to remove them
  • Processes - Enumerates running processes and allows you to kill them
  • Services - Enumerates services
  • Remote Desktop - Remote desktop into computer
  • Remote Assistance - Initiate remote assistance session with remote computer
  • View C Drive - Opens explorer to the C drive of remote computer
  • Send Message - Sends a message to all users on remote computer
  • Restart Computer - Restarts remote computer (Includes confirmation)
  • File Menu
    • Connect to domain... - Connect to a different domain
  • View Menu
    • View WSUS logs
    • View Event Viewer
    • View Services
    • View Local Users/Groups MMC

Usage: Download AWSA.zip and unblock the file (Right-click, Properties and unblock). Unzip AWSA.zip and open the AWSA.Options.xml file in Notepad to modify any settings.  To use the GUI, right-click the AWSA.ps1 script and select 'Run with PowerShell'.  Once the GUI loads, type in a partial computer name to search for it in Active Directory.  Right-click on a computer in the listbox and select it to move the name into the textbox.  If you already know the name of the computer you would like to manage remotely, you can type that directly into the textbox.

Download AWSA 2.0

Tweet Tips of the Week 12/04-12/10

Every now and then I like to tweet some quick tips or short commands that can be useful for System Administrators.  Here are some of my recent tweets:

12/08 - Remoted into a machine and can't find the Restart option? Use 'Shutdown /f /r /t 00' to force a reboot immediately.

12/07 - PowerShell network scanner - 1..254 | %{test-connection 192.168.1.$_ -count 1 | Select Destination,IPV4Address} 

12/06 - Enable/Disable the opening of multiple Outlook windows with a switch by changing your shortcut to 'Outlook.exe /recycle'.

12/05 - Want to use a GUI to shut down large a number of machines? Use 'shutdown /i' and you will be presented with a shutdown GUI.

12/04 - Don't have installed for WMI queries? No worries, use WMIC. 'wmic OS get Version'.

Arposh New User Creation (ANUC)

[Updated - May 13, 2012]


Download link: Arposh New User Creation v1.1

One task that every systems administrator has to go through at some point is the creation of new user accounts.  Over time, this becomes burdensome and tedious.  The Active Directory wizard takes you through multiple screens and you have to enter the same information multiple times in some occasions (e.g. a lot of organizations use FirstName.LastName for samAccountNames).  It also does not allow you to set all of the fields that you want included in the wizard.  I wanted a way to include those fields and an option to set defaults for some fields.  Luckily Powershell makes all of that possible in an easy to use way.  Powershell does all of the heavy lifting and an optional XML file saves even more time by pre-populating certain fields and setting defaults.  You also have the ability of bulk-adding users via CSV.  To create users from a CSV, click on File > CSV Mode.  You can then import the CSV and browse through the users in the CSV.  Once the CSV is imported, you can create one user at a time or all at once.  If you want a CSV template created for you, click on File > Create CSV Template.

ANUC Requirements:
- Powershell v2 (Minimum)
- ActiveDirectory module

Usage: Download the ANUC.zip file from the TechNet ScriptCenter and extract it into any directory.  Right-click on ANUC.ps1 and select 'Run with PowerShell'.  To modify the available options for drop-down lists and default entries, edit the ANUC.Options.XML file. To create users from a CSV, click on File > CSV Mode.  You can then import the CSV and browse through the users in the CSV.  Once the CSV is imported, you can create one user at a time or all at once.

Features:
  • Allows user creation with oft-used Active Directory attributes
  • Bulk creation of users from CSV
  • Auto-generation of account attributes based on other attributes
    • Display Name
    • samAccountName
    • userPrincipalName
  • Default entries
    • Domain
    • OU
    • Phone Number (can use full number or company prefix '212-555-')
    • Department
    • Company
    • Description
    • Password (Accounts are set to change at first logon)
    • Site (HQ, Branch Office 1, etc)
    • Street Address
    • City
    • State
    • Postal Code
  • Pre-populated fields for easy selection
    • Address information
    • Domains
    • OUs
    • Descriptions
    • Departments

Single-User Mode

CSV Mode

Inventorying vSphere VMs with custom attributes

I'm somewhat new to working with VMware's vSphere and have been teaching it to myself through Powershell.  Powershell has the advantage of being able to explore objects without having to worry about accidentally clicking on something that could take the environment down.  To stay as safe as possible, I started out with exploring the Get commands, the most obvious being Get-VM.  My first script was as basic as they get.

Get-VM 'myvm' | Format-List *

This gave me a basic list of properties that I could view.  Now I needed a way to store that information in a report.

Get-VM 'myvm' | Select Name,NumCPU,MemoryMB,UsedSpaceGB,Notes | Export-CSV C:\myVMs.csv

My new CSV was a good start, but there was other information that I wanted to capture.  I started digging into the objects nested deep in the VM and started creating my own properties.  The one-liner started to stretch a bit far, so I cleaned it up by breaking the lines at the pipes.

Get-VM 'myvm' | 
Add-Member -Name "GuestOS" -Value {$this.ExtensionData.Guest.GuestFullName} -MemberType ScriptProperty -Passthru -Force | 
Add-Member -Name "VMToolsVer" -Value {$this.extensiondata.config.tools.toolsversion} -MemberType ScriptProperty -Passthru -Force | 
Select Name,NumCPU,MemoryMB,UsedSpaceGB,GuestOS,IPv4Address,Notes |
Export-Csv C:\myVMs.csv

Now we're getting somewhere.  Almost any information that was built into the vSphere console and viewable was in my grasp.  While I was searching the internet for more things I could add, I came across a post from @LucD22 about custom attributes.  There were a few posts about creating and setting custom attributes, but no easy way to retrieve them that I could find.  So I set out to write my own.  This was my first attempt at gathering the information.

Get-VM 'myvm' | Select Name,@{l="Contact";e={$_.customfields | ?{$_.key -eq 'Contact'} | select -ExpandProperty value}}

The more I learn about Powershell, the more I become a stickler for standardization and I didn't like the look of that hash table when I added it into my previous script; it cluttered my Select-Object statement and made it harder to read which attributes I was pulling.  Once I cleaned up the script, I turned it into a function and it was ready for production.  Below is the final version of the script with help included.

Function Get-VMReport {
<#
.SYNOPSIS
Retrieves virtual machines from VMware vCenter
.DESCRIPTION
Retrieves virtual machines from VMware vCenter and returns summary information
.EXAMPLE
.\Get-VMReport.ps1
This returns all virtual machines from all default vCenters
.EXAMPLE
.\Get-VMReport.ps1 -vCenter vCenter01 -Credential $Credential
This returns all virtual machines from vCenter01 using the credentials stored in $Credentials
.LINK
http://blog.richprescott.com
#>

[CmdletBinding()]
    Param(
    [String[]]$vCenter = 'MyvCenter',
    
    [Parameter(Mandatory=$true,ParameterSetName="RunAs")]
    [Alias("PSCredential")]
    [System.Management.Automation.PSCredential]$Credential
    )

Connect-VIServer -Server $vCenter -Credential $Credential | Out-Null
Get-VM | 
    Add-Member -Name "vCenter" -Value {$vCenter} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "IPv4Address" -Value {$this.ExtensionData.Guest.IPAddress} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "GuestOS" -Value {$this.ExtensionData.Guest.GuestFullName} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "Datastore" -Value {Get-Datastore -VM $this} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "VMToolsVer" -Value {$this.extensiondata.config.tools.toolsversion} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "Contact" -Value {$this.customfields | ?{$_.key -eq 'Contact'} | select -ExpandProperty value} -MemberType ScriptProperty -Passthru -Force | 
    Select vCenter,Name,Contact,PowerState,VMToolsVer,GuestOS,numCPU,MemoryMB,Datastore,UsedSpaceGB,ProvisionedSpaceGB,IPv4Address,Notes
Disconnect-VIServer -Server $vCenter -confirm:$False | Out-Null
}
Get-VMReport | Export-Csv C:\Reports\vCenter.csv -NoTypeInformation

Arposh Client System Administration Tool (ACSA)

[Update] Arposh Windows System Administration tool 2.0 has been released and replaces the Arposh Client System Administration tool.

Download link:  Arposh Client System Administration

When I was first starting out in the help desk of a large company, everything was done by sneakernet.  I wanted a way to do things remotely to be more efficient, but was met with resistance by management who thought it was not 'improving customer service' because it lessened face time with the customers.  I tried explaining to my supervisor that the reason we have customers (i.e. the company's employees) is because they need to get their work done and they just want their computers to work.  Another hurdle that stood in the way is the retraining of the help desk staff in resolving issues remotely.  To solve the second issue, I decided that I needed a tool that brought the majority of the standard help desk applications to one place and made it easier to troubleshoot and fix issues.  The first issue resolved itself after management saw how quickly tickets were being resolved and how impressed the users were with the help desk's remote 'magic'.

The Arposh Client System Administration tool (ACSA) started out as a way to retrieve information from machines remotely.  When a user would call, you enter in the name of the computer they are using and it shows you basic information about the machine.  As the tool grew, it went from being only able to gather system info, to gathering local group information, installed software, startup items, running processes and viewing log files.  Now that the tool provided a plethora of information, there became a need to act on the information that was being gathered.  This led to being able to modify local admin groups, uninstalling software, removing startup items and killing processes on remote machines.

Since then, ACSA has grown to what you see below:



ACSA Requirements:
- Powershell v2
- Quest ActiveDirectory Tools for Powershell (http://www.quest.com/powershell)
- PSExec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553)
Optional: Trace32.exe (For tailing log files)

Usage: Run the ArposhCSA.ps1 script and type in a partial computer name to search for it in Active Directory.  This brings up a second form with a list of computers that match the search criteria and the users that are logged into them.  If you already know the name of the computer you would like to manage remotely, you can type that directly into the text box on the main form. 

Features:
  • Connects to currently logged-in domain on startup
  • Search for PC - Search Active Directory for computers matching the string in the textbox
  • System Info - Gathers info about PC, user session, make/model, hardware, OS, networking and McAfee
  • Local Admins - Enumerates local administrators and allows you to remove them
  • Applications - Enumerates installed software and allows you to uninstall
  • Startup Items - Enumerates startup items and allows you to remove them
  • Processes - Enumerates running processes and allows you to kill them
  • Remote Desktop - Remote desktop into computer
  • Remote Assistance - Initiate remote assistance session with remote computer
  • View C Drive - Opens explorer to the C drive of remote computer
  • Restart Computer - Restarts remote computer (Includes confirmation)
  • File Menu
    • Connect to domain... - Connect to a different domain
    • Find User in AD - Enter user's name, search for it in AD and output to Grid View
    • Find User on PC - Enter computer name, see who is logged into it and then search for that user in AD
  • View Menu
    • View McAfee AntiVirus logs
    • View WSUS logs
    • View Event Viewer
    • View Services
    • View Local Users/Groups
  • Quick Fix
    • Group Policy Update - Run 'gpupdate /force'
    • Lock Computer - Lock the remote computer
    • McAfee DAT Update - Updates DATS
    • Reader Fix IE Plugin - Update Reader's exe path in registry to fix IE plugin
    • Rename Computer - Renames remote computer and reboots it
    • WSUS - Detect - Run 'wuauclt /detectnow'
    • WSUS - Report - Run 'wuauclt /reportnow'
    • WSUS - Reset Client ID - Fixes an issue where computers do not show up in WSUS

Download link:  Arposh Client System Administration

In later posts, I will go into detail about how some of the functions in this tool work. Stay tuned! 

Disclaimer: This was the first GUI I wrote and some of the older code is not written with coding best practices in mind (clarity of variables, spacing, etc).  Be gentle.  As always, never run a script without knowing and understanding what it is capable of.  Just because it works in my environment, does not mean it will work in yours. Test, test, test.  Since you read the disclaimer, I'll also let you know that there are a few easter eggs hidden in the code that give extra functionality.  Cheers!

    Update: MDT 2012 Beta 1

    I recently posted about the release of MDT 2012 Beta 1 and wasn't too impressed with it. I have to say that my feelings are starting to change with two new blog posts from Michael Niehaus.


    The cross-platform support means that instead of having to use two separate boot methods (x86 vs x64) to deploy your operating systems, you can now just use the x86 CD or USB and your x64 task sequences will be available.  Two items to note:

    • Booting to an x64 environment and deploying x86 is still not supported.
    • Booting to an x86 environment to deploy an x64 image means that you will need to upload setup files for both instances of that OS (e.g. Win 7 SP1 - 6.1.7601.17514) x86 and x64.

    Now on the the good stuff...UEFI support. We've all grown to know and love the BIOS and have used it since the dawn of time (or so it seems).  UEFI is about to change all of that.  The BIOS has certain limitations that UEFI has been designed to eliminate.

    • 16-bit code (where most OSes are now 32-bit or 64-bit)
    • 1MB of addressable memory (regardless of how much the computer actually has)
    • Slower option ROM initialization
    • 2.2TB boot disk limitation (an MBR limitation)

    UEFI has been deployed in many of the newer hardware models, but has been set to 'Legacy BIOS' mode for backwards compatibility.  MDT 2012 will allow you to take advantage of 'native' UEFI, which addresses the issues listed above.  The first two changes that most IT pros will notice are the removal of the 2.2TB boot disk limitation and the improved boot times.  As the UEFI standard matures, we should see an even larger improvement in boot times, especially when matched with SSDs.

    For more information of the UEFI standards, visit http://www.uefi.org/specs/esp_registry.

    Add code snippets to Powershell ISE

    I have been looking for a user-friendly way to add code snippets to Powershell ISE to reduce typos and time spent copy/pasting.  Borrowing a page from Jeffery Hicks' blog, I took it a step further and used multi-line comments to add large code snippets to the ISE for creating new scripts.  As an example, I often write scripts that take advantage of the Quest ActiveRoles AD Management snapin.  The code below allows me to use ALT + F5 as a hotkey to insert this code into the ISE quickly and easily.


     $QADTools = @'
      function Add-QADTools
      {
      $Quest = Get-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction silentlycontinue
      if ($Quest)
        {
           Write-Debug "Quest.ActiveRoles.ADManagement Snapin loaded"
        }
      if (!$Quest)
        {
           Write-Debug "Loading Quest.ActiveRoles.ADManagement Snapin"
           Add-PSSnapin Quest.ActiveRoles.ADManagement
           if (!$?) {"Need to install AD Snapin from http://www.quest.com/powershell";exit}
        }
      }
      Add-QADTools
      '@
    
      $psISE.CurrentPowerShellTab.AddOnsMenu.Submenus.Add("Insert QAD Tools", `
    {$psise.CurrentFile.Editor.InsertText($QADTools)},"ALT+F5") | out-Null
    


    To implement this into the ISE, you will need to modify/create your Powershell ISE profile.  To find your user profile, you will need to browse to C:\Users\%USERNAME%\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1 and paste the above code into the .ps1 file.  This code will also add a new menu item to the Powershell ISE named 'Add-ons' with a menu item named 'Insert QAD Tools' as shown below.



    Retrieve PC make and model info from WSUS

    I came across a scenario where I needed to get the make and model of all of the client systems in my environment for reporting.  There are a few routes that I could take to retrieve this information (Inventory, WSUS, AV), and after briefly checking over each of them, it looked like WSUS was kept the most up-to-date for my purposes.

    
    $Server = "wsusservername"
    $Results = "C:\wsusmodels.csv"
    
    [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") |
    out-null
    
    $WSUS = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($Server,$False)
    
    $computerScope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope
    $computers = $WSUS.GetComputerTargets($computerScope)
     
    $Computers | 
    Sort-Object Model |
    Select-Object fulldomainname,ipaddress,make,model |
    Export-CSV -Path $Results -NoTypeInformation
    

    At the beginning of the script, we set some variables to determine the WSUS server that we will be connecting to and the location where we want to output the results.  We then load the assemblies for WSUS and connect to the server.

    [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") |
    out-null
    $WSUS = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($Server,$False)

    Once connected to the server, we need to create a computer target scope and then query a list of all computers in that scope.

    
    $computerScope = New-Object Microsoft.UpdateServices.Administration.ComputerTargetScope
    $computers = $WSUS.GetComputerTargets($computerScope)
    

    Now that we have a list of computer objects in the $Computers variable, we want to sort the objects based on the computer model, select the properties we want to report on, and export them to the CSV that was specified in the $Results variable at the beginning.

    Now you have a CSV with a list of all of the computers in your environment (that report to that particular WSUS server) and their IP address, make, and model.  Happy reporting!

    Convert DNS client cache into a Powershell object

    I was watching the TechEd video The Network Files, Case #53: Diagnosing Diseases of DNS and began thinking about an easy way to troubleshoot local DNS client cache.  The first command that came to mind was 'IPConfig /DisplayDNS', but it is a hassle to scroll through all of the output looking for what I wanted.  I ended up writing a short script to convert the results into a Powershell object that I could then work with easily.

    Function Get-DNSClientCache{
    $DNSCache = @()

    Invoke-Expression "IPConfig /DisplayDNS" |

    Select-String -Pattern "Record Name" -Context 0,5 |
        %{
            $Record = New-Object PSObject -Property @{
            Name=($_.Line -Split ":")[1]
            Type=($_.Context.PostContext[0] -Split ":")[1]
            TTL=($_.Context.PostContext[1] -Split ":")[1]
            Length=($_.Context.PostContext[2] -Split ":")[1]
            Section=($_.Context.PostContext[3] -Split ":")[1]
            HostRecord=($_.Context.PostContext[4] -Split ":")[1]
            }
            $DNSCache +=$Record
        }
        return $DNSCache
    }


    The script begins by invoking the IPConfig command that we all know and love.  A typical DNS record looks similar to the one below.

    Invoke-Expression "IPConfig /DisplayDNS" |

         docs.google.com
        ----------------------------------------
        Record Name . . . . . : docs.google.com
        Record Type . . . . . : 1
        Time To Live  . . . . : 78138
        Data Length . . . . . : 4
        Section . . . . . . . : Answer
        A (Host) Record . . . : 74.125.226.98


    Now that we have the information that we want, we need to weed out extraneous lines.  The first item that I wanted to capture was the record name.  The results of the Invoke-Expression are piped to the Select-String cmdlet with a pattern of "Record Name" and a context of '0,5'.  This command searches every line from the pipeline that matches the pattern, then shows zero lines before the match and five afterwards.

    Select-String -Pattern "Record Name" -Context 0,5 |

     >     Record Name . . . . . : docs.google.com
            Record Type . . . . . : 1
            Time To Live  . . . . : 80174
            Data Length . . . . . : 4
            Section . . . . . . . : Answer
            A (Host) Record . . . : 74.125.226.98

    We now have a group of objects from the pipeline with the information that we want, we can loop through them and create some Powershell objects.  This is done with the use of the ForEach (%) alias, New-Object PSObject and property splatting.  For the record name property, I can take the match of the Select-String, split it between the colon and set the property 'Name' to the item after the colon.  For the rest of the properties, the script has to pull the information from the postcontext of the match, which is then split and the property assigned to the items after the colon.

        %{
            $Record = New-Object PSObject -Property @{
            Name=($_.Line -Split ":")[1]
            Type=($_.Context.PostContext[0] -Split ":")[1]
            TTL=($_.Context.PostContext[1] -Split ":")[1]
            Length=($_.Context.PostContext[2] -Split ":")[1]
            Section=($_.Context.PostContext[3] -Split ":")[1]
            HostRecord=($_.Context.PostContext[4] -Split ":")[1]
            }
            $DNSCache +=$Record
        }


    Once each of the objects is created, it is added to the $DNSCache array that we created on the first line of the function.  The function then returns that array as a Powershell object that can be filtered, sorted and otherwise modified.

        return $DNSCache

    An example that could be used is shown below.

        Get-DNSClientCache | Sort Name | Format-Table Name,TTL,HostRecord -Autosize

    As I believe most Powershell users can attest in regards to work, "I've got 99 problems, but Powershell's not one."

    Microsoft previews Windows 8 Metro UI on a touchscreen

    Below is a preview of Microsoft Windows 8 (v.Next) running on a tablet with a touch-screen interface. Looks pretty fluid in their demo, but I wonder how it will handle multi-screen setups.  Should be pretty interesting to see which direction Microsoft decides to take.

    Full story from Microsoft...


    TechEd 2011 Powershell videos

    There were some good Powershell related sessions at this year's TechEd conference.  Unfortunately, there seems to have been fewer than at TechEd 2010, which is odd considering the uptake in users that it has seen in the past year.  Some of the sessions from this year include:

    Client

    Server

    You can watch the videos at the links above or download the slides/videos.   If you are already familiar with Powershell and you want a quick way to download TechEd Sessions automatically by using PowerShell, head on over to ScriptingGuys blog.

    MDT 2012 Beta 1 Released

    Microsoft Deployment Toolkit 2012 Beta 1 has been released. Some of the changes in this version:
    • New menus during capture/deployment.
    • More verbose info when executing task sequences.
    • Support for SCCM 2012
    • Various bug fixes.
    From what I have seen so far, there is not much reason to upgrade unless you are planning to implement SCCM 2012. The rest of the items seem like nice-to-haves rather than needs or feature sets.