Showing posts with label Powershell. Show all posts
Showing posts with label Powershell. Show all posts

Export SCCM task sequence variables with PowerShell

Whenever starting with a new technology or project, I try to gather as much information as possible to get an idea of what I'm working with.  I've recently started working with SCCM task sequences, and similar to MDT, there are built-in task sequence steps that cover the basic tasks that most system administrators need to perform.  However, as environments become more complex and we are asked to do more and to do it efficiently, we sometimes need to get deep into the weeds and pull out a hidden gem.

There is a trove of data that is required to perform actions in a task sequence that is hidden from view. SCCM uses this data to determine which servers to talk to, where packages are located, which step is currently running, and much more.  If we want to be able to use it, we need to know what is there. There are blog posts from years ago explaining how to export this information using VBscript, but this is 2017 and we deserve a PowerShell way to do it!  This code will export all task sequence variables, including those defined on collections and devices.



With the line below, we are creating a new PowerShell object based on the SCCM task sequence COM object and storing it in $TSEnv.
$TSEnv = New-Object -ComObject Microsoft.SMS.TSEnvironment
There are a few interesting methods to explore on this object, but for now we will focus on two of them:

  1. GetVariables()
  2. Value()
The first method allows us to query the currently running task sequence for the names of all available task sequence variables.  The second method returns the value of the variable specified inside the parenthesis.  By using both of them together in a loop, we can return a list of every variable and it's respective value and store it in a variable.  We then use Out-File to write the variables to a text file on the system drive (X: if run in WinPE).

Now we need to add the script to a task sequence and run it.  There are a few of ways to invoke PowerShell code in a task sequence:
  1. Run PowerShell Script step and providing a script name that exists within a package
  2. Run Command Line step and invoking PowerShell.exe with the -File parameter
  3. Run Command Line step and invoking PowerShell.exe with the -Command parameter
There are plenty of guides on how to use items 1 and 2 above, so let's play with the third.  To do this, we need to concatenate all of the commands so that they run in one PowerShell instance.  This can be done by using a semi-colon, which tells PowerShell to expect more code before exiting.  When done, it looks like this:


We can then paste this code into a Run Command Line step in the task sequence and deploy it to an SCCM client.  



After the task sequence completes, you will find a file in $ENV:SystemDrive\Windows\Temp named TSVariables.txt that contains a key=value listing of the variables.  One word of caution is that this exports ALL task sequence variables, including sensitive and masked variables such as the SCCM client push credentials (noted by a variable name starting with "_SMSTSReserved").  If you want to avoid exporting these, you can update the GetVariables code to match the code below.
$Vars = $TSEnv.GetVariables() | Where-Object {$_ -notmatch 'Password' -OR $_ -notmatch 'Reserved'}
You can add as many -OR statements to the code to filter sensitive information.  In a later post we'll go through some of the interesting variables and what they can be used for.

Quick Hits: Set-CMSite and Set-AdaptivaServer

It's eclipse star-gazing time, so the blog post this weekend comes to you from the road and features two functions that I have used extensively when working in my lab environment for SCCM and Adaptiva.

Set-CMSite

This function requires local administrator rights on the device and switches the site that your SCCM agent is connected to.  After execution, you can use my Get-CMLog function to follow along with the logs while your machine connects to the new infrastructure and starts performing registration activities.

Set-CMSite on Github



Set-AdaptivaServer

If you have any low-bandwidth locations being served by your SCCM infrastructure, you may have looked into ways to easily provide content to those locations.  One option is to use an Alternate Content Provider that can cache the content locally and uses P2P storage.  One that I have been testing is Adaptiva OneSite.  With multiple environments, having an easy way to switch a client from one infrastructure to another similar to how we do with Set-CMSite above, is crucial.

Set-AdaptivaServer on Github

Note: To maintain cached content at the branch site, you must use the built-in SCCM migration tool to mirror content to the new SCCM infrastructure and also publish the content to the new Adaptiva server.  Otherwise, the content will fail a hash check and will need to be downloaded across the WAN again.


Visualizing objects in the PowerShell console

Last week we talked about how to enhance time-based PowerShell objects by adding a duration. This provides useful metrics, but humans are visual by nature and it would help even more if we could visualize the numbers.  As with any task, I started my search for console visualizations by googling to see if anyone else had written something I could use.  I came across a blog post from Jeff Hicks in 2013 that showcased his PowerShell console graphing tool.  The console graphs were close to what I wanted to do, but in testing I found that dropping all of the other properties of the object didn't allow me to retain important and relevant data.

I set about modifying the function to my liking and ended up with the following changes:
  • Removed color-based conditional formatting for readability and ease-of-use
  • Modified the output to be object-based 
  • Added ability to specify columns to keep
The first modification ended up being more of a usability issue for me. My use-cases did not require changing colors of the graph and by removing this functionality, we reduce the complexity of the script and the number of mandatory properties.  Also, with the script leaner, it made my next tasks much easier.

In the process of updating the script, it became clear that meeting my requirement of retaining properties would also require returning objects instead of writing to the host.  After editing the code to maintain the objects passed into the function, it was simple enough to convert the Write-Host of the bars in the chart to instead add a new property with the bar as a string.

Once we had all of that code modified, I quickly realized that the more properties we specified and the greater the width of them, the less space we had for charting.  That's the exact opposite of the problem I originally had; now there's TOO much data!  By implementing my original requirement of being able to specify columns to keep, we are now actually restricting the data so that we can provide more helpful charts.

With the function complete, we can do fun things like chart the top 10 memory hogs:


And we can also get an idea of how many commands that PowerShell modules contain:



The Out-ConsoleGraph function is available on Github.



Enhancing time-based objects with duration

Often when troubleshooting we come across log files that have tons of data.  It can be hard to digest properly, so we look for tools that can break it down and provide some insight into what is happening.  Last week, I shared a blog post on parsing System Center logs with PowerShell.  If we use that function to convert the log lines into objects, we can now manipulate them and add calculated fields to provide even more data to assist in troubleshooting.

One of the important angles when troubleshooting is "How long did each task in the process take?". To answer this question, we need to take a look at each line in the logs and compare it to the following one.  With PowerShell, the pipeline processes each object one at a time, so how do we accomplish this with code?

The method that I came up with was to include a stutter-step for the pipeline.  Capture the first log line in a variable and hold onto it until the pipeline moves to the next entry.  We can then calculate the difference in the date/time fields and add it as a new property.  The second entry in the log then overwrites the first entry as the stored variable and we continue until the last entry in the log.  As it is the last entry in the log, we have nothing to compare it to, so we simply set it as a dash.



As you can see above, the Add-Duration function reads in the output of Get-CMLog, selects the UTCTime property for comparison, and adds the results to a property called TotalMilliseconds.

Depending on the duration of your logs, you may want to use one of the other options for duration such as Days, Hours, Minutes, or Seconds.  This is useful when troubleshooting long-running tasks such as OSD, or even when you just want to figure out what is taking a long time in the process so that you can track, trend, and reduce it.

And this function is not just for System Center logs.  It should work on any time-based object as long as you specify the property containing a [DateTime] field that New-TimeSpan can parse.

The full code is available below and on Github.

SCCM Log Parser

Anyone who has ever worked with SCCM loves and adores CMTrace.exe for it's ability to parse the System Center logs. Countless headaches have been adverted in it's name.  Still, it leaves quite a bit to be desired.  To address some of the short-comings, Microsoft has released CMLogViewer.exe.  This new tool supports quick filters, merging log files, and advanced filters.  Even with the added features, it still lacks the flexibility that PowerShell can offer.

I started my adventure to do more by searching online for anything that met my needs:
  • Read logs in the SCCM format
  • Parse a single log or multiple logs (must provide filename as a property)
  • Provide either local or UTC timestamps for global troubleshooting
  • Accepts logs directly or via pipeline

After not finding anything suitable, I set about writing my own.  Thankfully the fields in the log file are self-explanatory as key=value pairs and we can use basic regex to capture them.
  • Message
  • Time
  • Date
  • Component
  • Context
  • Type
  • Thread
  • File

To satisfy the local and UTC timestamps requirement, I had to add some additional regex capture groups that were then passed to the [DateTime]::ParseExact .Net method.  I then added the fields into a [PSCustomObject].  The regex and object were then wrapped in a foreach loop that processes log lines read in via Get-Content.  Since I also had a requirement of passing in multiple files and showing which line came from which log, I captured the current file name via Split-Path and also added that as a property to the object.  And to support the ability to specify logs through the pipeline, a Process block was added and then a loop to read in each file.

Meeting these requirements allow us to do fun stuff like the following:

Show me the log entries in SMSTS.log
   Get-CMLog smsts.log

Show me all log entries for CM logs and sort them by date
   Get-ChildItem -Path C:\Windows\CCM\Logs | Get-CMLog | Sort-Object UTCTime
Show me any log entry with "Error" in the message text
   Get-CMLog -Path .\SMSTS.log | ?{$_.Message -match 'Error'}

Show me all log entries for logs that contain an error
   Get-ChildItem -Path C:\Windows\CCM\Logs | Select-String -Pattern 'error' | Select -Unique Path | Get-CMLog

The full code is available below and on Github.

Arposh New User Creation tool comes out of beta!

With the impending start of the 2012 Scripting Games, I had the urge to script.  Thanks to that, the Arposh New User Creation tool has been updated and is now at version 1.0!

New in 1.0:
  • Updated to be compatible with PowerShell v3 Beta
  • Enter custom sAMAccountName, Display Name, and userPrincipalName in single-user and CSV modes
  • Turn off auto-generation of sAMAccountName, Display Name, and userPrincipalName in single-user mode
  • Better error-handling during user creation
  • Set new accounts as enabled or disabled
  • Set 'Password must change at logon' to enabled or disabled 
  • Minor bug fixes
To download the new release and see more information, check out the download page on the TechNet ScriptCenter.

PowerShell Training: Back to Basics



PowerShell is quickly taking over IT departments and with such big names behind it, it’s no wonder.  If you already use PowerShell, chances are that you have used a module or snap-in from one of the companies below:

Microsoft
VMware
NetApp
Cisco
Intel
Quest

For those not familiar with PowerShell, when they see how quickly or easily things can be configured or automated, they of course want to get in on the action.  So how do you go about introducing someone to PowerShell and make them self-sufficient?  You give them a link to www.ScriptingGuys.com and tell them to study up. But what if I am giving them an in-person demo?  I show them my guide to using PowerShell for the first time and then usually start out with these five* commands:

Get-Command

The first thing that people usually want to know is, ‘What can I do with PowerShell?’  At that point, I load up the console and tell them to type in Get-Command.  A long list of available cmdlets starts scrolling by and you can see their eyes light up.  Once they find a cmdlet that interests them (there always is and most of the time it has to deal with a current issue they are facing), I move on to the next command.

Get-Help

This is my go-to command; I use it more often than any other.  If I ever come across a command that I want to use, but don’t know how, Get-Help is my first stop.  To see more details for a cmdlet, you can use one of the following:

Get-Help -Examples
Get-Help -Detailed
Get-Help -Full
Get-Help -Online

I’ve found that the –Examples switch is the best for beginners, as it gives them an idea of what can be done with the command and lists the information that they need to accomplish the task.  With these two cmdlets, they have more than enough to get started and get some work done.  Once they have had a little bit of practice, I continue on with where it gets really interesting, modules!

Get-Module / Import-Module

As with most IT professionals, you and the trainee have probably worked with a technology from at least one of the companies listed at the beginning of this post.  Did you know that they all provide PowerShell modules or snap-ins that help you automate their products?  To view all modules that are available on your machine, just type Get-Module –ListAvailable at the PowerShell console and you should see a list of each one available and the commands included.  If you were looking for one of the modules from a vendor listed above, be sure to download and install it first, then re-run the Get-Module cmdlet.  Once the modules are installed, you can import them using Import-Module .  Now you can use the commands you learned previously to view each of the cmdlets available in the module and their usage:

Get-Command –Module

Note: Some of the vendors are still providing their cmdlets in snap-ins, which is legacy for PowerShell v1.0.

Get-Member or Format-List

At this point, the trainee should have a general understanding of what PowerShell is and how to use it.  Depending on the background of the person, I tailor the last section for their professional background.  For anyone with a developer background, I typically show them Get-Member, as it shows them all of the methods, properties and other membertypes, which they are familiar with seeing.  For the IT Pros learning PowerShell, I typically stick with Format-List.  This gives them the information system administrators and technicians are looking for and when they are more comfortable, I loop back and show them Get-Member.

And that wraps up my beginner’s guide for PowerShell.  You provide the who and why and I provide the what and how.  ‘When’, you say?  The time for PowerShell is NOW!

Resources:
  1. Popular PowerShell Modules 
  2. Windows Features/Roles that use PowerShell 
  3. PowerShell-enabled technologies

Using PowerShell for the First Time

So you want to use PowerShell for the first time and you can’t figure out where to start.  You right-click on a PowerShell script that you downloaded from the internet and you are prompted with a security warning, or maybe you see some error messages and then the PowerShell window disappears.  Here are some simple advice to make sure your first PowerShell expedition is a successful one.

Make sure you are using the latest version of PowerShell

The PowerShell team has a great blog post which lists all available versions of PowerShell and related downloads.  If you are using Windows 7 or Server 2008 R2, you already have PowerShell 2.0 installed, but if you are using a previous OS, you will need to download the most recent version.  As of this posting, the latest production release is v2.0, which requires .Net Framework Version 2.0 to be installed.  It is recommended to install .Net Framework Version 3.5 SP1, as this is required for the Integrated Scripting Environment (ISE) and graphical cmdlets.

Opening the PowerShell console

There are numerous ways to access the PowerShell console (when installed) and I’ll list just a few of them for you here.

  • Taskbar
    • An icon that looks like a blue square with >_ in white lettering
    • Windows 7 and Server 2008 R2 (by default)
  • Start Menu
    • Start > Programs > Accessories > Windows PowerShell > Windows PowerShell
    • Windows XP/Vista/7 and Server 2003/2008/2008R2
  • Windows Explorer
    • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    • Windows XP/Vista/7 and Server 2003/2008


Configure the Execution Policy for PowerShell

Configuring the PowerShell execution policy requires access to a user account that has local administrator rights to the system that you wish to configure.  To begin the process, locate the PowerShell executable at one of the locations listed above, right-click the icon and select ‘Run As Administrator’.  If UAC is enabled, you will be required to accept a security warning.  You should now have a blue PowerShell console with a title of ‘Administrator: Windows PowerShell’.  To see the current execution policy, you can use the Get-ExecutionPolicy cmdlet.  In a default install of PowerShell, the value Restricted will be returned. To change the policy, use the Set-ExecutionPolicy cmdlet. 

For more information on available execution policies and how your system will be affected, you can read the about_Execution_Policies documentation.

Guest Article on Microsoft's Hey Scripting Guy blog

Hi Everyone!

Just stopping by to let you know I was featured on Microsoft's Hey Scripting Guy blog with an article discussing the Microsoft community and how you can benefit from it.  Check it out!

-Rich

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!