I’ve been working on a PowerShell support function to assist service desk personnel and escalation teams in diagnosing issues on client systems. Recently I finished uploading my work to GitHub and creating milestones and a planner to track development.
You can find the code on GitHub at this link – https://github.com/bytesizedalex/Get-SupportInfo
Please note – this code has been designed for Windows 10 clients. PowerShell cmdlets and functionality may not exist on legacy, deprecated operating systems. The function may work on older operating systems but it will likely fail to output expected data in all instances. I suggest reviewing the frequently asked questions on the GitHub repository for more information or updated details.
One of the biggest challenges in troubleshooting is having the right data to make informed decisions. On many occasions the service desk person has to guess at what data may be required and to which team the ticket should be assigned. Should they assume the ticket needs passing to the network team they may only gather data that team has previously asked for. The network team may review the ticket and determine the issue needs to be passed to infrastructure. What happens then? Quite likely the infrastructure team will ask for more information relevant to their team.
Now our poor service desk employee has to try and get back on the problem machine and gather more information. Perhaps the issue is transient and no longer exhibiting on the endpoint, we’ve lost data which could have helped us resolve the ticket!
What we really need is to gather all the data in one go in a simple, easy to use manner. The data should be in a structured format to make it easy to ingest to other platforms and review by humans.
We want to make sure the data we capture is gathered at the same time. If we don’t do this there is the potential that transient issues pass and a retrospective information capture misses the data we need. Even if the issue remains, we are now working on two different sets of data which can make event correlation challenging.
This function aims to resolve these concerns. We ensure that all data defined as useful by support teams is captured at a point in time and saved to a single archive. This archive can be attached to a service desk ticket and used by all escalation teams. We have one common view of the problem which makes it easy to compare findings.
For service desk teams this function streamlines data capture. No longer do they need to remember or reference multiple escalation team documents outlining the information which should be gathered in different scenarios.
Captured data is saved in structured formats wherever possible, typically in the form of CSV, XML and EVTX files. There are a small number of files which do not follow this principal. Typically this is because review is easier in the native format (e.g a HTML webpage) and I want to reduce friction in reviewing data.
You may notice that some information will be captured by multiple output files. While it would certainly be desirable to have a single copy, cmdlets or external executables often lacked the full range of data required. Considering the small size of support archives this is not considered a problem.
Let’s take a look at the output from Get-SupportInfo
Firstly, all captures are saved to C:\Support\ – you could of course change this location if you desired. Each capture is stored as a single Zip archive which is named using the format computerHostname-timestamp.zip
You will notice a folder named ‘Logs’ – this is where our function writes the output. The folder is cleared on completion of a capture, it is also cleared on initial run to ensure fresh runs do not include spurious data.
The file LogFile.txt is a PowerShell transcription log, this can be useful if our function has problems during runtime. It is intended for use by the code maintainer but support staff can review to check for obvious problems if desired. This file is not overwritten, we simply append output to it. This does mean the file will grow as people execute the support tool but it shouldn’t be an issue for most. I am considering an enhancement which caps the file to a specific size and then performs some form of maintenance.
If we look in the file it is your standard PowerShell transcription, in this case there was a single cmdlet which threw an error. This was expected and used for this demonstration.
Let’s take a look at our support bundle – the archive file contains data useful to various support teams. I won’t go through every file but you can get a feel for the information based on the file names. Exported Windows EVTX event log files are stored in the EventLogs folder.
If you’re wondering how much space these logs can take, well that depends! If you set your EVTX Windows event logs to be very large then that will increase the output size. The rest of the data however is relatively small, especially once archived. The example above was 65.8MB raw data which compressed to 5.62MB. That’s pretty good considering we’re just using the standard Windows PowerShell command to archive a file as a Zip.
I wanted to see how this compares to trusty 7zip archiving the same data to a .7z file. Unsurprisingly the results were even better, our 65.8MB raw data compressed to 2.47MB! You may ask why I don’t use 7zip, well the simple answer is I’m trying to avoid dependencies on third part code and programs being present. This function calls PowerShell cmdlets and Windows executables and I think I’d like to keep it that way.
If you are interested in the code and testing it for yourself I highly recommend reviewing the GitHub repository. I’ll include the current help summary in this blog post but please be mindful this is subject to change.
This function will generate and output various log files and support information to assist in troubleshooting computer issues. The exported data is added to an archive file which can be attached to support tickets or forwarded from service desk to senior support. The function requires a directory named 'Support' exist at 'C:\Support'. The function will attempt to create this directory if it does not exist. As part of my standard build this is created in the operating system deployment process. If you have limited users ability to write or create directories on this drive or location you will need to amend the function. The following summarises the data captured - > MSInfo32 saved to NFO file > Get-ComputerInfo > Event Logs exported to EVTX files > Test for elevated access and export if running as Administrator - > Microsoft-Windows-Diagnostics-Performance/Operational > Security > Export at all times - > System > Application > Microsoft-Windows-CertificateServicesClient-Lifecycle-System/Operational > Microsoft-Windows-CertificateServicesClient-Lifecycle-User/Operational > Microsoft-Windows-Ntfs/Operationa > Microsoft-Windows-Ntfs/WHC > Microsoft-Windows-OfflineFiles/Operational > Microsoft-Windows-Storage-Storport/Operational > Microsoft-Windows-TaskScheduler/Maintenance > Microsoft-Windows-TaskScheduler/Operational > Microsoft-Windows-WLAN-AutoConfig/Operational > GPResult Report Exported to HTML file > Get-HotFix > Get-Process > Get-Service > Get-Disk > Get-Volume > Get-NetAdapter > Get-NetIPConfiguration > Get-DnsClient > Get-DnsClientGlobalSetting > Get-DnsClientServerAddress > Get-NetFirewallProfile > Get-NetFirewallRule > Resolve-DnsName - Test lookup of internal domain resource and external Internet resource > Generate Wireless LAN Report > Export Active Directory Site information using .Net > Get-BitLockerVolume - Test for elevated access and export if running as Administrator > Get-Tpm > Export computer and user certificate store information > Export system environment variables > Get-Printer > Export time synchronisation using W32tm /stripchart compared to current Active Directory PDC Emulator > Get-ScheduledTask > Get installed software from registry entries in HKCU and HKLM > Get-LocalUser > Get-LocalGroupMember > Export Physical Memory information from CIM (Win32_PhysicalMemory) > Export Processor information from CIM (Win32_Processor) > Export BIOS/EFI information from CIM (Win32_BIOS) > Export Reliability Records from CIM (Win32_ReliabilityRecords) > Export PNP Device information from CIM (Win32_PNPEntity) > Export PNP Device driver information from CIM (Win32_PnPSignedDriver) > Generate PowerCfg Power Scheme Report, including currently active scheme > Generate battery report if battery CIM instance exists > Generate system power report - Test for elevated access and export if running as Administrator > Generate DirectX Diagnostic Report All output is saved to C:\Support\Logs\ and is then added to an archive file. Following archive creation the Logs folder is cleared of all files. Archive files are not removed automatically as support staff may wish to capture multiple data sets during troubleshooting. PowerShell transcription is used to capture logging information, the log file is located at 'C:\Support\LogFile.txt' The function is designed for Active Directory domain joined machines. Certain data captures will fail to work on a non-domain joined system or will have data missing. Please note - on completion the function will clear the contents of $exportFolder. By default this is set to C:\Support\Logs.
Once again, you can find the code repository here – https://github.com/bytesizedalex/Get-SupportInfo and I welcome your feedback and suggestions.