All of the scripts that we’ve written for the monitoring system have been powered by lists of severs. Where do you get the lists from? You use a script to generate them of course! You could easily configure each of the monitoring scripts to run independently by filtering AD for a specific set of computers and storing them in a variable instead of using a file, but the list method has several advantages.

In our case we want to run multiple scripts against the same group of servers repeatedly. Searching AD over and over again for the same data isn’t very efficient. Especially when it’s a list of machine names that rarely change. That being said, servers do get added and removed. Typing them in a list and calling it a day is a recipe for crap cake surprise. The solution is to script the lists so that they are dynamic.

How you get the lists is going to be dependent on how your Active Directory is structured. I have a pretty strict naming convention in place, so I run filters against the names. You might need to search specific OUs or some other property (see code in box 3).

For example, all my production domain controllers are named PRODAD**** so to build a list of them:

Get-ADcomputer -Filter {name -like "prodad*"} -Properties dnshostname|
select dnshostname -ExpandProperty dnshostname|
out-file C:\Sources\Prod\ad_servers.txt

Create lines like the one above, for each group of systems that you want to monitor. The output path must exist before you run the script or you’ll get errors. My example is C:\Sources\Prod\ so you need to make those folders on your C drive or change the path. I suggest that you create a group of folders on the IIS server you plan on running your monitoring from and storing the files there.

If you need multiple names for a filter just use -or and add as many as you need.

Get-ADcomputer -Filter {name -like "prodexch*" -or name -like "prodmbx*"} -Properties dnshostname|
select dnshostname -ExpandProperty dnshostname|
out-file C:\Sources\Prod\exchange_servers.txt

After you have code for all of your groups, you should consider adding a catch all at the bottom. This will add servers that don’t follow the standards to a file. We all have them LOL. In my environment I search the servers OU that a GPO drops our servers into and add every system that doesn’t match one of my previous groups to a Misc_servers.txt file. Note that the example below uses “-notlike” and “-and” versus the “-like” and “-or” we used above.

Get-ADComputer -Searchbase "OU=Production Servers,OU=Servers,OU=MY_Server_OU,DC=MY_DOMAIN,DC=com" -Filter
{name -notlike "prodad*" -and name -notlike "prodexch*" -and name -notlike "prodmbx*"}|
select dnshostname -ExpandProperty dnshostname|
out-file C:\Sources\Prod\misc_servers.txt

Once you’ve put it all together, run the script and you should end up with a text file for each group of servers in your Active Directory. Open the files and you should see the FQDN for each server that matched its filter, each on a separate line. You can use these lists as the input parameters for the monitoring scripts we’ve already written in PowerShell Monitoring Part 1, PowerShell Monitoring Part 2, and PowerShell Monitoring Part 3.

As you’ll see in a future article regarding remote systems management, these dynamically built lists of servers by type can be used for other useful projects as well. My production script ended up with 19 of the “type” filters plus the “catch all” so expect to spend some time getting this right on your network. Next in this series we’ll configure an IIS server to run all of these scripts as scheduled tasks and display the HTML files.

Every admin or engineer who has installed a Windows Server Update Services server (WSUS) on their network has had to choose between sever-side and client-side targeting. The choice between flexibility and automation can often be a difficult one to make. Maybe it doesn’t have to be? PowerShell allows us to access the internal workings of WSUS and customise them to our liking. Read-on to see the method I came up with for allowing the flexibility of server-side targeting with automated group assignment.

For those who are unfamiliar with WSUS targeting options, server-side targeting allows an administrator to add or remove systems to or from WSUS groups in the software’s management console. Many of the companies I have worked for like to periodically change-up their patching routines. This usually means modifying your update groups. For example; perhaps all the SQL servers are currently grouped / patched together but the new Director wants them patched with the applications that use their databases. These types of changes occur in real-time and are simple to manage in the GUI when you’re set up for server-side targeting. The drawback to this option is that someone has to sort all of the computers into the correct groups manually; if your network has a lot of nodes, the task can be daunting. Furthermore, admins will need to watch for the addition of new systems and sort those into the proper groups.

The other option is client-side targeting. In this configuration, you create GPOs that tell each OU they are linked to, what group those servers belong in. This automates the sorting process but is much less flexible. In the example above, to regroup our SQL servers we would need to create new GPOs for the OUs that contain them and remove the old ones. Then we’d need to wait for all the replication and registration to occur which can take a very long time on large networks.

With a little PowerShell know how, we can close the gap between the server-side setup that most admins would prefer to run (who doesn’t like flexibility) and the client-side config you almost feel forced to run on a large network. WSUS has had a dedicated PowerShell interface since the 2012 edition. You can use PowerShell on the older versions, but you need to manually load the assemblies and the command structure is slightly different (Google it).

First, if you haven’t already, you’ll need to install the RSTAT tools for your operating system. You’ll also want to install the SQL Server 2012 CLR Types and SQL Server Report Viewer runtime. The RSTAT tools will add the PowerShell module for WSUS to your system and the other pieces will let you run WSUS reports if you need them.

For WSUS to see your systems at all, you’ll need to point each server’s Windows Update service at your WSUS server. The easiest way to do this is with a GPO linked to the top-level server and/or workstation OU(s) in your domain. You’ll need to configure the Specify intranet Microsoft update service location and the Configure Automatic Updates policies.

DO NOT CONFIGURE the Enable Client Side Targeting policy.

Your WSUS server should be configured for server-side targeting. If you don’t do this, the options for moving computers to new groups will not be available in the management console at all. The setting is in the WSUS managment console.

If everything has worked out, all of the systems that we’re going to manage patching on will now be in the “Unassigned Computers” group. This is exactly where we need them be. Having them in this group means that our script can be much simpler. We won’t have to check for connectivity, SSL, RPC, and all that jazz because the systems wouldn’t show up in the “Unassigned Computers” group if that stuff wasn’t working. In fact, if you have systems that didn’t show up, you need to start checking those protocols and settings. You’ll also want to be sure that you didn’t miss an OU with the GPO that is configuring the update services to point at your WSUS server. If you opted to encrypt the traffic to and from WSUS, you’ll also want to make sure you CA and Root certs are trusted by the client systems.

Now you’ll need to configure all your Target Groups in WSUS. Until you get the hang of how this technique works, I suggest that you create a group for each of the system OUs in your Active Directory. This makes sorting easier to implemeant and explain. Once you understand how everything works, you’ll have no problem customizing things. It is important to keep in mind that because we’re using server-side targeting, computers can belong to more than one patching group, this will not cause any kind of conflict. WSUS only patches a computer once with any given patch so whichever group applies the update first wins.

Before proceeding, you’ll need to import the ActiveDirectory and WindowsUpdate PowerShell Modules (see the first two lines below). There are lots of ways to access WSUS through PowerShell (this is Windows after all) but one of the easiet is to call the connection every time that you want to use it. We can use this code to build a list of the computers in our Unassigend Group. Make sure you adjust the portnumber parameter to match your situation. The code below is referencing the default encrypted port for the manangment console.

#Import the modules we need:
Import-Module ActiveDirectory
Import-Module WindowsUpdate
#Build a list of the unassigned computers names:
$NewServersFull = Get-WsusServer
-Name WSUS_Server_Name -PortNumber 8530|
Get-WsusComputer -ComputerTargetGroups "Unassigned Computers"|
select Fulldomainname -ExpandProperty Fulldomainname

Notice that we assigned that list of computer names to a variable? We’re going to run these computers through the Get-ADComputer cmdlet to see if it belongs to a particular OU. The Get-ADComputer cmdlet tends not to like FQDNs as an identity parameter so we need to shorten our names to just the NETBIOS portion (strip off the domain name).

$NewServers = Foreach ($server in $newserversfull) {
$server.split(‘.’)[0]
}

Now $NewServers is an array containing our short server names. This list can be used as the identity parameter in a Get-ADComputer loop. That loop is going to check to see if a computer belongs in a given OU. I like to create functions for each system OU in my Active Directory and then loop the list of names through each. When a system matches the OU I’m coding for, I insert it into the correct WSUS target group. Here’s what one of those functions looks like.

Function MY-OU-NAME {
$MY_OU_NAME = Foreach ($server in $newservers) {
Get-ADComputer -Identity $server -Properties * |
Select dnshostname,canonicalname -ExpandProperty
canonicalname| Where canonicalname -Like
"mydomain.com/mydomainsite/ToplevelOU/Servers/*"|
Select dnshostname -ExpandProperty dnshostname
}

Foreach ($server in $MY_OU_NAME) {
Get-WsusServer -Name WSUSSERVERNAME -PortNumber 8530|
Get-WsusComputer -NameIncludes $server|
Add-WsusComputer -TargetGroupName "MY - WSUS - GROUP"
}
}

The * on the end of the canonicalname is important, it allows the where statement match every system in that location. You could also use the filter and searchbase parameters to search the OU directly, instead of the canonicalname. I don’t because I had already generated a list of canonicalnames for all my OUs for another project and I’m lazy 🙂 . If you want to find the canonicalname for an OU, just pick a computer in the OU and run Get-ADComputer -Identity computername -Properties *|select CanonicalName or use ADUC.

Copy and paste a new function into your script for every OU that has computers you want to assign to a WSUS group. For each (man I type that a lot) function, you’ll need to change the Function Name (MY-OU-NAME), Variable Name (MY_OU_NAME), and the WSUS target group name (“MY – WSUS – GROUP”).

At the end of our script we can use a little logic to prevent the process from running if there aren’t any new computers in the unassiged group. We can also send a report showing the servers that were added. Or, we can notify someone that the script ran but there weren’t any new servers to add.

If ($newserversfull.count -gt 0 ) {
$body = $newserversfull|out-string
FunctionName
FunctionName
FunctionName
Send-MailMessage -SmtpServer my.email.server
-From report@wsus.mydomain.com
-to my-email@mydomain.com
-Subject "WSUS Servers Added"
-body $body
}
Else {
Send-MailMessage -SmtpServer my.email.server
-From report@wsus.mydomain.com
-to my-email@mydomain.com
-Subject "WSUS No New Servers this time -EOM"
}
$leftovers = Get-WsusServer -Name WSUS_Server_Name -PortNumber 8530|
Get-WsusComputer -ComputerTargetGroups "Unassigned Computers"|
select Fulldomainname -ExpandProperty Fulldomainname
If ($leftovers.count -gt 0) {
Send-MailMessage -SmtpServer my.email.server
-From report@wsus.mydomain.com
-to my-email@mydomain.com
-Subject "Systems that coudn't be grouped by WSUS"
-body $leftovers
}

That last little bit ($leftovers) runs the same code we started with. If our script has done its job, there shouldn’t be anything left in the unassigned computers group. If there are computers still in there, you’ll want to know so that you can manually intervene.

All that’s left is to schedule the script with task manager to run automatically with credentials that have enough permissions to manage WSUS. I set mine up to run twice a day; just create a new scheduled task and in the action set the comand to “powershell.exe” and in the arguments put “the\file\path\to\myscript.ps1” and set the trigger to your desired frequency. When you save the task it will prompt you for the credentials it should run with (be sure to check the box to run whether a user is logged in or not).

I call my little piece of magic “The_Sorting_Hat.ps1” (yes, I’m a Harry Potter fan). Its been a life saver. When I need to move a computer to a new group, I just launch the WSUS console and put it there. Since the system isn’t in the unassigned computers group the script has no effect on it. I can manually create new groups for adhoc needs and add systems to multiple groups, all while not worrying about new systems hanging around without being patched.

Many environments have patching processes or other updates that reboot large numbers of systems. Occasionally, when those systems boot up, some of their services fail to start. It takes too long to logon to each server and manually check and start failed services. PowerShell can do the job for us.

The code below will import a list of server names (text file with only the hostnames) and scan each server in the list for services that are set to automatic. If any of the servers’ automatic services are discovered to be stopped it will try to restart them.

The script will then report on all of the automatic services except those that stopped normally.

$servers = Get-Content C:\servers.txt
$report = @()
Foreach ($Server in $Servers) {
Get-WMIObject win32_service -ComputerName $server -Filter "startmode = 'auto' AND state != 'running'" | Invoke-WmiMethod -Name StartService
$wmi = Get-wmiobject win32_service -Filter "startmode = 'auto' AND Exitcode =0" -ComputerName $server
$report += $wmi | select-object @{n="ServerName";e={Get-WmiObject win32_computersystem -ComputerName $server|select name -ExpandProperty name}}, @{n="ServiceName";e={$_.name}},@{n="Status";e={$_.state}},@{n="Start Account";e={$_.startname}}
}
$report|export-csv C:\Services-Report.csv -NoTypeInformation

You can make this operation more dynamic by replacing the $servers variable with code to find all of the $servers on your network. It would also be easy to output the $report to an email message or HTML dashboard.

Enjoy.

After you’ve cranked out a few reports in PowerShell, either you or your boss will eventually wonder if it can be used to create an uptime report. A quick search of the Internet will return lots of options for calculating the uptime by subtracting the lastboottime, obtained via WMI, from the current date. This technique works well but few if any of the articles suggest how you go about creating a report that shows the information for all of your Windows Servers.

I tried a handful of the scripts I found on-line and didn’t like the results so I decided to write my own. The code below will scan your window’s domains and locate a domain controller in each. It will contact those domain controllers and scan for computer objects whose operating system contains the words “Windows Server”. Next it will connect to each of those computers and use WMI to calculate the uptime. Finally it will create a report showing each server’s Name, Operating System, and Up Time.

It would be simple to have the report scan workstations instead. Just change the word “Server” to “Workstation”, you could also add an and statement to do both. Emailing the report would be cinch as well (Search for PowerShell SendMail) and the script already written in a manner that would support running it as a scheduled task.

Enjoy.

Import-Module ActiveDirectory
$domains = (Get-ADForest).domains
$dcs = Foreach ($domain in $domains) {Get-ADDomainController -DomainName $domain -Discover -Service PrimaryDC}
$servers = Foreach ($dc in $dcs) {
Get-ADComputer -Properties * -Filter {(OperatingSystem -like "*Windows Server*")}|Select DNSHostName -ExpandProperty DNSHostName
}

$report = @()

Foreach ($Server in $Servers) {
$wmi = Get-WMIObject -Class Win32_OperatingSystem -ComputerName $Server
$lastboottime = $wmi.ConvertToDateTime($wmi.LastBootUpTime)
$sysuptime = (Get-Date) - $lastboottime
$uptime = "$($sysuptime.days) Days, $($sysuptime.hours) Hours, $($sysuptime.minutes) Minutes, $($sysuptime.seconds) Seconds"
$Report += $wmi | select @{n="Server";e={$_.CSName}}, @{n="Operating System";e={$_.Caption}}, @{n="System Uptime";e={$uptime}}
}
$Report|Export-CSV $env:userprofile\documents\Windows_Server_Uptime_Report.csv -notypeinformation

It can be difficult to know what applications are installed on the machines in any given company. Not knowing what is installed where, can lead to all kinds of trouble when updates are pushed and changes are made. Enterprise class tools like System Center that can create a CMDB are expensive. So what’s an Admin supposed to do?

If your budget won’t allow you to purchase a tool or pay a DEV team to write you one; you’ll have to do it yourself. PowerShell is always my goto tool for this kind of thing on a Windows network. You could accomplish the same goal with VBS or even CMD batch files, but if you are running systems so old that you have to resort to those tools, you have bigger problems than worrying about what apps are installed.

If you’ve spent time researching this, you’ve probably seen several techniques to get the data that you’re after. I like connecting to the registry and searching the 32 bit and 64 bit uninstall keys because it is fast, accurate, and has a lot of info available. You could also use WMI/CMI, scan the Program Files directories for exe files, and more. As with everything in any kind of programming; the hard part isn’t getting the data, it’s out-putting it into something useable. Lucky for you I’ve included that feature in my script.

The code below will locate your AD Forests and find domain controllers in each of them. Next it will scan for objects that contain “Windows Server” in the Operating System description and add those object’s DNS host names to an array. It will ping each server in that array to see if they are real and on-line, because AD can have dead objects in it. Then it will add the systems that are up to another array and for each of those, the script will remotely access the registry keys that contain the uninstall data. The uninstall data will be used to create a CSV report that lists each application’s name, version, help link, and install date along with the name of the machine.

Import-Module ActiveDirectory
$domains = (Get-ADForest).domains
$dcs = Foreach ($domain in $domains) {Get-ADDomainController -DomainName $domain -Discover -Service PrimaryDC}
$servers = Foreach ($dc in $dcs) {
Get-ADComputer -Properties * -Filter {(OperatingSystem -like "*Windows Server*")}|Select DNSHostName -ExpandProperty DNSHostName
}

Foreach ($server in $servers){
$PingTest = Test-Connection -ComputerName $server -Count 1 -Quiet
If ($PingTest)
{
$servers += $server
}
Else
{Write-Warning "Failed to connect to server '$Server'."}
}

$report = @()
ForEach ($server in $servers) {
$report += Invoke-Command -ComputerName $server -Command {Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object @{n="Application"; e={$_.DisplayName}}, @{n="Version"; e={$_.DisplayVersion}}, HelpLink, Publisher, InstallDate | Sort-Object Application}
 }

$report | Format-Table -AutoSize
$report |select -Property * -ExcludeProperty RunspaceID, PSShowComputerName|Export-Csv -Path $env:userprofile\documents\windows_servers_cmdb.csv -NoTypeInformation

You’ll need to have the RSTAT tools installed or run the application from a Server that has them. To be successful you’ll also need enough privileges to scan the remote machines registry and your network can’t be blocking WinRM. Other than that, just save the code to a PS1 file and run it. The report will be in your Documents folder named windows_servers_cmdb.csv.

If you want to adjust to scan apps on workstations just change the filter keyword to “Windows Workstation”; you could also do both. To fully automate it just add a line at the bottom to email the attachment and schedule it to run as a task. If you want to get really creative convert the table into HTML and upload it to an IIS or Apache host every day. If you have SharePoint you can upload it to a custom list and then create some pretty killer reports. Views that filter for key words like “Exchange” or “SQL” are helpful for everyone.

Be sure to tell your boss it took you all week to do this LOL.

I’ve gotten to the point where I manage most things in my day job with PowerShell. It’s a lot faster to type Unlock-Account kjtrent; than it is to launch ADUC and find the account. I also don’t like having to open one tool for AD, one for Exchange, and another for Lync/SfB. Furthermore, I have separate credentials for signing on to my workstation and managing servers.

I’ve created a simple little PowerShell script that will prompt for credentials and use them to open remote sessions (no need to install anything) to the servers. Copy the code below and save it in a PS1 file. Enter the FQDN of your servers in between the quotes for the appropriate variables. Then make a new desktop shortcut with the following path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit “C:\Users\profile\Documents\AdminShell.ps1” and pin the shortcut to your start menu. When you double-click it you’ll be prompted for credentials and a PowerShell window will open with the remote sessions loaded. It will stay open until you close it.

#Enter the FQDN for your servers below between the "
$exchfqdn = "your exchange server fqdn"
$sfbfqdn = "your Skype for Business / Lync FE Server FQDN"
$adfqdn = "your DomainController FQDN"

$ErrorActionPreference = 'SilentlyContinue'
$WarningPreference = 'SilentlyContinue'
$UserCredential = Get-Credential -Message "Credentials are required to access AD, Exchange, and SfB; use the detected username or enter a differerent account" -UserName ($env:userdomain +'\'+ $env:USERNAME)
$ExSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://$exchfqdn/PowerShell/ -Authentication Kerberos -Credential $UserCredential
$SfBSession = New-PSSession -ConnectionUri https://$sfbfqdn/OCSPowerShell -Credential $UserCredential
$ADSession = New-PSSession -ComputerName $adfqdn -Credential $UserCredential
Import-PSSession $ExSession
Import-PSSession $SfBSession
Import-PSSession $ADSession

If you’re in the process of migrating to or setting up a hybrid relationship with Office 365 SaaS offerings you probably want to simplify the login process for your users. There are a ton of articles and setup guides out there that explain how to set up Azure AD Connect and even AD FS if you need it but one thing that is more difficult to figure out is setting the UPN. The UPN is a logon in the format of an email address instead of the more common domain\username NTLM nomenclature. Office 365 prefers UPN logons and to be honest they’re easier in your on-premises Active Directory as well.

To prevent your users from needing to logon twice in hybrid environments and to make the UPN easier to remember in on-premises authentication it makes sence to set it to match the user’s email address. The script below assumes you have created a csv file of the user accounts that you want to modify. At least one column in that csv needs to be a qualified identity parameter (SamAccount, Distinguished Name, etc.). When you run the script it will ask for the file and then for the name of the column containing the ID parameter. After you’ve provided those, it will loop through the file and set each user’s UPN to match their current email address.

Import-Module ActiveDirectory
[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
Start-Transcript -Path "$env.userprofile\documents\upnupdatelog.txt"

Function Get-FileName($initialDirectory)
{
 [System.Reflection.Assembly]::LoadWithPartialName("System.windows.forms") | Out-Null

$OpenFileDialog = New-Object System.Windows.Forms.OpenFileDialog
$OpenFileDialog.initialDirectory = $initialDirectory
$OpenFileDialog.filter = "CSV files (*.csv)| *.csv"
$OpenFileDialog.ShowDialog() | Out-Null
$OpenFileDialog.filename
} #end function Get-FileName

# *** Entry Point to Script ***

$userlist  = Get-FileName  

$idcolumn = [Microsoft.VisualBasic.Interaction]::InputBox("Enter the case sensitive name of the column that contains the employee's account information:","SamAccountName, DN, CN or Name Column", "ID")

$usernames = Import-Csv -Path $userlist | select $idcolumn -ExpandProperty $idcolumn

Foreach ($user in $usernames)
{
    $address = Get-ADUser -Identity "$user" -Properties proxyAddresses | Select -Expand proxyAddresses | Where {$_ -clike "SMTP:*"}
    $newUPN = $address.SubString(5)
    Set-ADUser $user -UserPrincipalName $newUPN
}