powershell

Secured WinRM SSL session and PowerShell WinRM queries – example with a PRTG sensor for CPU, HDD and RAM

Secured WinRM SSL session and PowerShell WinRM queries – example with a PRTG sensor for CPU, HDD and RAM

Windows Mangement Remote Mangement / WinRM can be configured as HTTPS / encrypted connection instead of using clear text transfer of the provided information. In order to do this you need to configure it accordingly and have a valid machine certificate installed on the system.

Now – the advantage here is clearly the added security layer while you request and receive those information. More information on how to do this can be found here: https://support.microsoft.com/en-us/help/2019527/how-to-configure-winrm-for-https

Only it becomes a challenge when you want to use PowerShell and e.g. PRTG to use this HTTPS encrypted system. I came across this request and had to create a script that actually works with such an HTTPS encrypted SSL session to WinRM. You can find it below.

What it does is rather simple:

  • set the CimSessionOptions to use SSL
    • additionally it bypasses the certification checks by default – you might want to adjust this depending on your network configuration
  • it creates a new CimSession to your target system using the UseSSL option
  • and finally it executes a few queries against this session
  • the data in this example is then translated in to a PRTG compatible XML structure so you could use it in a Advanced EXE/XML sensor within PRTG

The data in this example combines information about the CPU(s), HardDrives / HDD(s) (only installed drives, not USB) and Memory usage to PRTG in a single sensor while using channels.

Due to some dynamic of the script, you want to make sure you have fixed upper and lower error limits on especially the channel Total Disks – so if something changes you can re-create the sensor due to it’s fixed channels once it did run the first time.

In theory you could provide limits within the XML response to PRTG – this is up to you – I always liked it more to configure them solely in PRTG in the sensor channels so I could adjust them per device.

PS: This was originally posted in the private PRTG channel on SpiceWorks here.

PRTG 911 call alerts – ShoreTel

PRTG 911 call alerts – ShoreTel

This is a PRTG 911 calls sensor script that I wrote a long time ago – it seems like there is quite some interest in it so I decided to write a blog post about it.

ShoreTel writes by default Windows Eventlog entries for 911 calls. The challenge we had is to inform HR / Human Resources and Facilities about such calls and let them know from which phone it was initiated.

While engaging PRTG we solved this while constantly checking for the specific Windows Eventlog EnventID 1319 in the Application log and raising an Error if the Event happened. We had to put a script in between and filter the event entry out to gather minimal data in the end for the event and notification that is send out to the specific HR and Facilities members.

First the script here:

Save the script in this path:

C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXE

Now add a custom EXE sensor (not the advanced) to PRTG and select the script. The expected parameters are the SERVERNAME and an INTERVAL – suggestions: SHORETELSERVER and 2 – 2 as interval assuming you scan every minute / 60 seconds / this will look for entries in the logfile within the last 120 seconds while accounting for any slack and keeping the error state alive for 2 to 3 minutes in PRTG.

Set the channel upper limit to 0 – if the script detects the Windows event you will get a 1 one back that indicates the error.

Set the scan-interval to 1 minute respective 60 seconds

Further might you want to add a special e-mail notification with the format TEXT WITH CUSTOM CONTENT and a target email recipient group for whom it concerns. See the screenshots below for some examples…

The email message body looks like this (example):

1 # (Value) is above the error limit of 0.90 # in Value (Emergency Services Call to 911 on port 10.10.10.10 from user ADDRESSBOOK NAME at 1234 (Extenstion))

 

 

PowerShell – custom tables or objects

PowerShell – custom tables or objects

Powershell sometimes can be challenging. One of the more confusing things is collecting data and having them in proper formatted tables / objects to process them further.

The below script is a sheer example on how you can accomplish this while creating a table, adding the needed columns and then filling the table with rows – in this specific example while reading network adapters and filling in IP information – if available – partly multiple rows (one row per IP and adapter) and partly single rows for adapters with not IPs.

Custom tables or custom PowerShell objects example with foreach loops to fill them up and combine values from various commands in to single tables for further processing.

 

Read the UEFI stored Windows key and activate Windows

Read the UEFI stored Windows key and activate Windows

The following script will read the UEFI stored Windows licensing key and show it – it then will attempt to activate Windows and probably even e.g. your Microsoft Office installation – this is not necessarily intentional by the script, rather then a coincidence that I discovered by using this script to activate Windows after it was automatically deployed from an image that had a pre-injected volume license key. Office likely got activated along with Windows.

In any case – it helps you to activate Windows or simply read out your license key.

 

Updated domain join script including KeePass / Pleasant Password server entries for local admins

ns a website from a systems administrator for systems administrators Home IT-Admins CMDB IT-Admins tool IT Search EOL Solutions Blog Contact Links Updated domain join script including KeePass / Pleasant Password server entries for local admins

Today I post an updated version of the domain-join script I initially posted here.

In theory you can just replace the script with the new version – assuming you did not make any changes other then adjusting it to your domain / server-names.

What changed in the newer version:

  • the top lines in the script hold the basic configuration parameters
    • line 1: NetBIOS name of your Active Directory domain
    • line 2: your DNS domain name
    • line 3: your distinguished domain name / root DN of your domain
    • line 4: your default OU for new workstations
    • line 5: empty
    • line 6: KeePass / Pleasant Password Server URL
    • line 7: KeePass folder to store the password in
  • the script now relies on the above parameters rather then specifying them in various areas in the script, making the whole use / adjustment of the script way easier
  • advanced error handling
    • after the user entered the computer name and his domain admin credentials the systems checks if it can connect to the domain and if the computer name already exists
      • if the domain credentials are invalid (can be a non-admin – as long they are valid) you get a message explaining that the script will stop due to wrong credentials
      • if the computer name already exists in the domain, you get a message about it and the script stops
    • KeePass or Pleasant Password Server connection – if it fails to connect with the credentials provided, you get a message about it and the script will stop
  • adjusted messages with various colours
    • white text – standard as it was before
    • yellow text – highlighted information so it sticks better out for the end-user
    • magenta text – handled error / failure message – this is an explanation that something stopped the script from going further
    • red text – those are real PowerShell error messages – either due to not handled errors or if the error was handled plotted out to the screen as additional reference and help

For additional information, please look at the original post here.

This script is also mentioned on the API Examples page on the Pleasant Solutions web site here.

Gathering profile information from computer

Gathering profile information from computer

Every now an then you might need to know who logged on and when was the last logon of which user to a specific workstation as well as the size of each user profile. For this I once wrote the PowerShell script you can find below. It does a WMI query against a list of one or more target computers and reads out the information reporting it back.

As input parameter use a comma separated list of computer names – those must be reachable and administrative accessible (you need at least admin rights on the target system). You then get a output set per profile.

The output can e.g. be transformed with the parameter |ft to see it in table format – like typical in PowerShell.

Output values are:

  • ComputerName
  • ProfileName
  • ProfilePath
  • ProfileType
    • Temporary
    • Roaming
    • Mandatory
    • Corrupted
    • local
  • IsinUse
  • IsSystemAccount
  • Size
    • this needs to most processing time – it is a manual size check including even temp files.. – other then what Windows shows you
  • LastUseTime

Monitor user accounts in Active Directory with PRTG

Monitor user accounts in Active Directory with PRTG

The following script will read through your current Active Directory and filter for user accounts with the following specific conditions:

  • Lockedout users – please read below for further information about this
    • all users that are lockedout
    • must be an enabled user
    • that is not expired
  • disabled users
    • all users that have been disabled
  • expired users
    • must be an enabled user
    • the expiration date is set and past the current date
  • users with password never expires set
    • must be an enabled user

This will give you a pure counter output per channel in an for PRTG Extended script sensor XML result.

But there is a theoretical flaw in one of the methods – the locked out users. Now, user accounts get locked out in Active Directory due to too many logon attempts with an invalid password. This causes Active Directory to set the lockedout bit in the object properties. The issue here is that this bit will not be set back to 0 after the defined lockout duration (GPO) is past, the property will only be set back to 0 once the lockout duration is passed and he successfully logged on.

This means, the counter might give you more results then currently true, it might count users that have been locked out but the lockout-duration passed – but they did not yet logon successfully. This is somehow a false positive, while not totally false. In any case, you need to be aware of this.

The script could be more efficient as well in the way it filters a few things, so far I optimized it as far as I could – the LockedOut value can not be set as a -Filter, in theory it might be possible to speed it up with a -Filter to the UserAccountControl (if that is even possible – not tested) – but I am not certain this would work. If you really want to speed it up you would need to work with -LDAPFilter – but this actually needs to completely replace the internal filter capabilities of Get-ADUser – you can’t use both – it is one or the other.

This script updated with a corrected version as of February 2019 and was also posted in the PRTG knowledge base here.

Prevent ScreenSaver coming up with a PowerShell script

Prevent ScreenSaver coming up with a PowerShell script

In our daily business, we often have the issue that a GPO enforces a screensaver after a certain amount of time. This can become very annoying and actually even be an issue if you are remote in on a end-user system and don’t know their password. After doing quite some research I found out that PowerShell actually is able to help here and I wrote a script to prevent the screensaver from coming up.

First I thought, let’s see if I can control the mouse cursor, cause I thought it would be less invasive, this is actually possible – but interestingly did not have the expected effect and the screensaver kept coming up. So I did go with keystrokes, but of course I was worried about what key would be save to send. Doing some research on Microsoft websites (here the link), I found the F16 – testing around with it I found it the least invasive key to send periodically to a system – it does not even exist on a regular keyboard and can only be simulated with a key-combination. To simulate F16 you need to press SHIFT + F4 – there might be a Windows 10 (may be even earlier) combination out of WINDOWS + SHIFT + F4 respective WINDOWS + F16 what would cause a shutdown. Once I found out about that, I decided to adjust the script to F17 what seemed to bypass even that small chance of an issue that would be more problematic then the screensaver itself – you sure don’t want the system to shutdown :-).

The script you find below can be simply executed. It has a setting $minutes that you could add as a parameter and therefor adjust it when you start it – by default it will use 9999 what is a pretty long time. To be clear – this is actually not a minute interval, it is a 30 second interval and ends up in half minutes. Why? Simple – Windows has a minimum setting of 1 minute that an screensaver can come up. If the script would fire in a minute interval, there is a theoretical chance the screensaver would still win.

This is further not pure PowerShell code – well it is but actually the key stroke is send via a Windows Scripting Host WSH / WScript command SendKeys. The PowerShell only surrounds to command. It has the nice habit of having a PowerShell window open that you simply can close to end the script. If you would do the same in WSH you would need to execute the script more manual with CSCRIPT rather then just double-clicking the file what would execute it via VBSCRIPT instead causing a hidden window / process and you would need to identify it in the task-manager to kill the process. Therefor, PowerShell was the best choice in the end to accomplish the task.

Additionally you could use the below more advanced script that will control the screensaver only during a defined time window. This is a more advanced way and more usable in certain situation, cause it would automatically allow the screensaver to come up outside the defined time window and minimize the exposure of the system more. It is also more effective then completely disabling any screensaver GPO settings, cause it is more specific and adjustable.

Update: As of 10/202 I updated the script below from F13 to F10, as this works better for most situations. Be aware, it all depends on what your foreground windows will react too. Make sure the keystroke you use does not cause you any harm.

Automate your SUS clean up

Automate your SUS clean up

Many companies rely on WSUS respective SUS services from Microsoft – aka. Windows Server Update Services as internal source and control of their update deployment to clients and servers within their network.

One of the big challenges for IT is to keep them clean and performant. The Cleanup-Assistant in the SUS management console tends to run forever and in any case means manual labor over and over again.

Below are two scripts – a CMD script that needs to be adjusted with parameters and a powershell script that will be called with those parameters. The scripts acutally will call the same API as the MMC Assistant does, just that this can be automatically performed via a scheduled task in Windows.

It helps you to keep your SUS slim and more performant.

In any way – I highly recommend to not blindly just enable all categories rather then limiting it to the once you have in place as well as once you reached a certain patch-level even actively denying updates you never will need again (keep in mind, new rolled out systems might still need older updates – but you could possibly refresh your base images or rely on Microsoft update services / online updates for those cases).

The combination of making updates obsolete and actually running a cleanup periodically will improve your SUS server performance.

As for the parameters, those are explained in the CMD script header – therefor I will not explain them here again.

Solarwinds Web Helpdesk – Slack alerts

Solarwinds Web Helpdesk – Slack alerts

This was originally posted here by myself: https://thwack.solarwinds.com/thread/114863

Solarwinds WebHelpDesk is very powerful, but for those who use Slack as communication and alerting platform, there still is no integration.

We as a IT team struggled a bit keeping up with the immense flow of emails and filtering them out as well as being really pro-active on new tickets (first response time) as well as realizing we got new tickets assigned or a user / client wrote a new note.

To overcome those challenges and due to the fact that we all have Slack on all our systems from workstation to smartphone, we decided to integrate this. Since I spend a bit of time on those scripts and thought they might be helpful for others as well, I am sharing them here now and explain on how to implement this.

Please note: Those scripts are a version 1 – I am very aware that they could be further cleaned up and simplified.. but I wanted to share them already… bugs are possible as well…

Requirements:

  • You need Solarwinds WebHelpDesk
  • The scripts use the field “Pager” in “Techs” for the Slack-Username – put all the Slack-Usernames of your Techs in this field – no @ – just the name
  • The scripts assumes you are executing it directly on the server that has the PostgreSQL database installed
  • The scripts assumes the database user/pw is defaulted to WHD

How to implement them:

  • Create the 5x files as show further below in e.g. “C:\Scripts\WHD” on the PostresSQL server
  • Create a new Windows Task that starts the WebHelpDesk_SlackAlerts.cmd file every 30 minutes
    • this file actually executes the PowerShell Scripts – it is just a work-around – it bypasses any PowerShell Script execution restritions
  • download the PostgesSQL ODBC drivers from the following link – assuming you haven’t installed them on the system already
  • Edit the PRTGSlackWebHookNotificationPSv2.ps1
    • This file was originally from our PRTG installation and modified there already. It was further modified for WHD alerts – I do not claim to have invented this script nor do I want to abuse any copyrights on it! source: www.paessler.com for monitoring solutions
    • Line 41: adjust the URL for the FavIcon.ico to your external WebHelpDesk URL
  • Create a new WebHook-Application in your Slack Account
  • Edit the CheckNewTicketsFirstResponse.ps1
    • This script posts to a generic channel in our case – we want to see new tickets as a group – assuming assigned tech is currently unavailable and couldn’t touch it…
    • adjust the PostgresSQL settings – if needed – IP / Port / User etc…
    • Line 7 – ticket_age_minutes = 88
      • this is a minute value – we alert on a Slack-Group “helpdesk” if there is a ticket older than 88 minutes – we fire the script every 30 minutes, so it could be up to two hours old..
    • Line 9 – $channel – adjust this to the Slack-Group channel you want to use for those alerts
    • Line 77 – adjust the URL to your external WebHelpdesk URL
    • Line 99 – adjust the Link to your own WebHook URL
  • Edit the CheckTicketAssigned.ps1
    • This will send the message to the Tech directly through the SlackBot channel – only he will see it
    • This will only fire if the Tech did not yet put a Tech-Note in the ticket after it was assigned to him
    • adjust the PostgresSQL settings – if needed – IP / Port / User etc…
    • Line 7 – entry_age_minutes = 32
      • this is a minute value – we run the scripts every 30 minutes – the alert due to some variable time can not be older than 32 minutes by default…
    • Line 74 – adjust the URL to your external WebHelpdesk URL
    • Line 97 – adjust the Link to your own WebHook URL
  • Edit the CheckTicketNewClientNote.ps1
    • This will send the message to the Tech directly through the SlackBot channel – only he will see it
    • This will only fire if the Tech did not yet put a Tech-Note in the ticket after the client / user did leave a comment or note
    • adjust the PostgresSQL settings – if needed – IP / Port / User etc…
    • Line 7 – entry_age_minutes = 32
      • this is a minute value – we run the scripts every 30 minutes – the alert due to some variable time can not be older than 32 minutes by default…
    • Line 74 – adjust the URL to your external WebHelpdesk URL
    • Line 97 – adjust the Link to your own WebHook URL

After that you should be all set.

We have further integration in to PRTG while monitoring the database for “new tickets older than 120 minutes” and looking for the logfile “SlackLogErrorDetails.txt” indicating that a Slack notification did not go through by the script – most likely due to special characters that the scripts already should take care off, but in case it happens again this file would appear. You can integrate that as well with your monitoring system, but this is beyond the scope of the simple notifications.

Other logfiles show just what was send out and indicate that everything is working well.

Click here to download the scripts archive WebHelpdeskSlackFiles.zip

Monitoring Shadow-Copies with PRTG

Monitoring Shadow-Copies with PRTG

This was originally posted here by myself: https://kb.paessler.com/en/topic/65026-monitor-shadow-copies-age#reply-247626

This is my solution for it – we monitor specific drives we enabled for shadow copy and wanted to see amount of shadows, newest should be within x hours and oldest should be at a minimum n hours – those limits can be configured with the limitations rather easily.

Main issue is – we talk about WMI modules that are only available in x64 if you use a x64 system. Now PRTG is executing sensors in x86, even thought it is installed on x64. Now, played around a while and came up with this simple solution.

Parameters for the parser-script (the one you need to execute) are: %host C: %host D: etc.

Parser script, needs to be in EXEXML directory: Name: Get-ShadowCopyStatsXMLx64parser.cmd

PS1 script, should to be in EXEXML directory – if not, adjust path in parser script: Name: Get-ShadowCopyStatsXML.ps1

PS: yes, the PS1 could be further optimized, but it took me already a while to find out the main issue was the x86/x64 combination, what is not possible – see Microsoft articles in MSDN/KB for more information while the Shadow-Copy WMI modules are only available in x64 on a x64 system.

Hope this helps others with the same challenge 🙂

Advanced PRTG Slack notifitications

Advanced PRTG Slack notifitications

This PRTG slack notification script was originally posted by myself here: https://kb.paessler.com/en/topic/66113-how-can-prtg-send-notifications-to-slack#reply-249147

This is our version of the script originally provided with PRTG by Paessler. – we are using the #colorstatus as well to determine to current issue and we are using actually icons to show the status – this is working pretty well for us. Besides that, reformatted the whole notification a bit so it is easier to read in the prtg slack notification messages.

Simple Slack example

It is easy to adjust and even use additional statuses/color-codes if needed..

Using PowerShell for Text-to-Speech

Using PowerShell for Text-to-Speech

PowerShell can be used for TTS / Text-to-Speech. In this specific example, PowerShell will be used for Paessler/PRTG (www.paessler.com) text-to-speech notifications. It will actually run against a remote-system in this scenario in a central NOC/Network Operations Center room and announce down sensors/systems. This was originally posted by myself on https://kb.paessler.com/en/topic/79674-can-we-have-the-ability-to-set-audio-notifications-when-sensors-go-down-up.

You simply create the script in the path C:\Program Files (x86)\PRTG Network Monitor\Notifications\EXE and create a new notification for it.

The parameters should be configured like this:

-TargetComputer ‘COMPUTER123’ -Device ‘%device’ -Name ‘%name’ -Status ‘%status’ -Message ‘%message’

Replace the COMPUTER123 with what ever client should play the sound – in our case this is the workstation that shows the MAPs on a TV and the sound actually comes out of the TV.

You might need to enable remote power shell execution on the target system, a hint for this is the following command: Enable-PSRemoting -Force

Here is the script file: Name: PRTGtoWorkstationText2Speach.ps1