Sunday, May 13, 2018

BREAKING NEWS: Powershell isn't always the answer

Greetings!


It is hard for me to say that Powershell isn't the end all, be all for automation.  But, at times, the simplest solution is the best.  In this case it was stopping and starting custom applications.


We have a server that needs to run two custom applications.  We will call these App1 and App2.  These applications have to be running in the foreground.  The first script stopped the applications by using a .bat file that contained the following code:
TASKKILL /IM App1.exe /F
TASKKILL /IM App2.exe /F


The script to start the applications contained the following code:
START C:\app1.exe
START C:\app2.exe


We were using Task Scheduler to run the scripts every morning at 4:00am.  When the tasks ran, the apps would stop but the apps wouldn't start in the foreground.


At first we thought we could create a Powershell script to get the applications to run in the foreground.  Unfortunately, we had the same problem when we created a scheduled task to run the Powershell script.


As we were trying to figure out why this was happening, our boss, Amos, came into the room and asked if he could take a look at the scheduled task.  After a minute he said, "I found the problem. You have to use Run only when user is logged on.  This setting will start the applications in the foreground.  Using Run whether user is logged on or not will force the applications to start in the background."  We made the changes and the applications started correctly.


So, we learned that it is necessary to know how to use the tools that will run your scripts.


I hope you find this useful.


Mike

Monday, April 30, 2018

Web Site Restart

Greetings,
We have had occasion to find a way to restart a web site when we get a notification that the site is unavailable.  The restart process includes restarting the associated application pool (app pool) and the site itself.  In PowerShell, this task is simple to accomplish.  The code is as follows:

$wstate = Get-Website -Name 'Default Web Site'

$pstate = Get-IISAppPool -Name DefaultAppPool

if ($wstate.state -ne "Started") {

Restart-WebAppPool -Name DefaultAppPool

Start-Website -Name 'Default Web Site'



}

We will use the Default Web Site in this example.  The first line ($wstate = Get-Website -Name 'Default Web Site'), gets all the information regarding the default web site, including its state (started, stopped).  The second line ($pstate = Get-IISAppPool -Name DefaultAppPool ) gets the information regarding the app pool for the default web site.

Within the IF statement, if the state of the website ($wstate) is not 'Started' then the app pool is restarted (Restart-WebAppPool) and the web site is started (Start-Website).

To verify the site has started you can add the following commands to start a browser and browse to the site:
$url = 'http://<your web site>'

$ie.Visible = $true

$ie = new-object -ComObject internetexplorer.application

$ie.Navigate($url)

I hope this information is helpful. 

Mike

Monday, April 23, 2018

When did these Pings run?

Greetings.

Took a little break from the blog.  I'm back and I have a script I created for my colleague, Tom.

Tom called me and wanted to know if there was a way to get time stamps when pinging a server.  To clarify, show a time stamp for each return value from the ping. In addition, the script should run like the Ping -t command and dump the output into a text file.

I researched how to ping within Powershell and found that the Test-Connection cmdlet will do what Tom has requested.  I started by creating a variable that will be used by the While loop

$i = 1

Then, we create the While loop
While ($i = 1){


}
This will run the commands within the loop until $i is something other than 1.

Now, we create the body of the script.  We will run the script against Google (www.google.com)

test-connection www.google.com | select @{N='Time';E={[dateTime}::Now}},@{N='Destination';E={$_.address}},replysize,@{N='Time(ms)';E={$_.Responsetime}} | export-csv -append c:\ping.txt

In the 'select' statement:
@{N='Time';E={[dateTime]::Now}}....This will create a column called 'Time' and this column will hold information from the [dateTime]::Now expression

@{N='Destination';E={$_.address}}...this will create a column called 'Destination' containing the information in the $_.address field

replysize...this is the size of the reply pack in Bytes

@{N='Time(ms)';E={$_.ResponseTime}}...this will create a column called 'Time(ms)' containing the information in the $_.ResponseTime field

The last part of the statement will send the output to a file called Ping.txt in a comma-separated value (CSV) format

In the end, the script will look like this:

$i = 1

While ($i = 1) {

test-connection www.google.com | select @{N='Time';E={[dateTime]::Now}},@{N='Destination';E={$_.address}},replysize,@{N='Time(ms)'; E={$_.ResponseTime}} | export-csv -append c:\ping.txt
 
} 

Some of you may be saying, "There isn't any code that changes $i to something other than 1."  And you would be correct.  This script will run until you manually stop the script, in most cases by using CTRL-C.

The output of the script will look like this:
 


 I hope you find this script helpful.  Be sure to comment if you have any questions.

Mike

Monday, April 9, 2018

Remoting into Workgroup PCs and a Book Recommendation

Greetings!

While trying to connect to a workstation on our network I discovered the workstation wasn't on our AD domain but was configured for WORKGROUP.  That got me thinking, "Can I access WORKGROUP machines via Powershell?".  And, by golly, you can.  Here's how:

Prerequisite work (this needs to be done on each PC you want to access):
Make sure the workstations are within the same IP and subnet mask range

Open your firewall settings
On the left panel, select "Allow an app or feature through Firewall"
Click on "Change Settings".  This will give you access to the apps and features in the list.
Scroll down and select Windows Management Instrumentation (WMI).
Click on the Private box
Scroll down and select Windows Remote Management
Click on the Private box
Click on OK
Close the Firewall window

Configuring Powershell:
Open Powershell with elevated privileges
At the prompt, type:
new-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name LocalAccountTokenFilterPolicy -propertytype DWord -value 1
  NOTE: the LocalAccountTokenFilterPolicy setting sets how admin credentials are applied to a
               remote computer.  A value of 1 is what is used to build the evaluated token
At this point you should be able to create a PSSession to your computer by typing:
enter-pssession localhost
 You should see a prompt similar to [localhost]: PS C:\Users.
Type exit-pssession  to exit out of the session

If all of the above tasks work on both computers, you should be able to create a session from one computer to another.  For example, I have two test workstations, 192.168.100.5 and 192.168.100.6.  In order for me to create a session from 100.5 to 100.6, I will do the following:
On 100.5
   enter-pssession -computername 192.168.100.6
The prompt will look list [192.168.100.6]: PS C:\users

From here I can start and stop services/processes.  I can create files and directories.  I will be looking for a way to copy files from a session to the host.

Again, to disconnect the session, type exit-possession

I know this seems like a lot of steps just to allow PSRemoting to WORKGROUP computers.  But I know there are still some environments where they have non-domain computers.  Why should they be deprived of experiencing Powershell's greatness?

Now, my book recommendation.
I don't do book reviews as well as I should.  But, Don Jones' new book, "Be The Master", is worth reading.  The main theme of the book is that we all have something to share/teach others.  Mr. Jones uses the analogy of the master and apprentice.  The master would share all of their knowledge with the apprentice, sometimes at the cost to the apprentice.  This allows for a craft/talent to move on (and sometimes is improved upon) to future generations.  What I got out of this book is that there are people out there who want to know things that I know.  That is why I post stuff to this blog.  I love Powershell and I want to share some of the things I have found.

It's a quick ready (about 105 pages) and is available via Amazon at $8.

Well that's what I have for this week.  I hope you found both items helpful.

Mike





Monday, April 2, 2018

My Process Stopped Processing

Greetings,
Last week I was tasked to create a Powershell script that detects the status of a process running on a Windows 10 computer.  If the process wasn't running, the script had to start the process.  If the process is in a 'suspended' state, the script had to stop and restart the process.  If the process was running, the script display a message.


Detecting the status of the process is relatively simple to do.  The first thing you want to do is store the process information in a variable.  We will call the variable $process:


$process = get-process myprocess -ErrorAction SilentlyContinue


It is necessary to add the -ErrorAction SilentlyContinue in order to get an empty variable if the process is not running.


Once we have the status of the process, you will have to check if the process is running.  To do that we will using an IF statement:


if ($process)
     {
      
     }
else
     {
        invoke-expression "c:\processes\myprocess.exe"
     }


If there is something in the $process variable, then we will check the status of the running process.  If the variable is empty, then we will start the process using invoke-expression (I will explain this later in the article.


So, if $process is not empty, the next step is to determine if the process is responding.  One of the attributes of $process is .Responding.  Within the brackets under the IF statement, use the following commands:
{
     if ($process.Responding)
     {
       Write-Host "Process is running"
     }
     Else
     {
        Stop-Process -name myprocess -Force
        invoke-expression "c:\processes\myprocess.exe"
     }
}


This code checks the status of $process.Responding.  It will either be True or False.  If the process is responding, then a message is returned.  If the process is not responding, the process is stopped by force, and the process is restarted.


The reason for using invoke-expression is because my process has a user interface that must be visible when it is running.  I couldn't use start-process because the interface would not appear.


The entire script will like as follows:
$process = get-process myprocess -ErrorAction SilentlyContinue
if ($process)
     {
       if ($process.Responding)
        {
          Write-Host "Process is running"
        }
     else
        {
          Stop-Process -name myprocess -Force
          invoke-expression "c:\processes\myprocess.exe"
        }
     }
else
     {
        invoke-expression "c:\processes\myprocess.exe"
     }


I hope you find this script helpful.  Be sure to add a comment if you have any questions, comments, or corrections.

Monday, March 26, 2018

What are these Execution Policies? And, how can they help me?

Greetings!

I have been writing scripts for a while but I haven't been too concerned about the scripts do since I'm only gathering information and not changing anything.  Then, I started creating scripts that create and update Active Directory accounts.  I want to make sure that the scripts don't create havoc within AD or any other part of the server.  To do this I looked to Execution Policies.

Execution policies are used to set the rules for Powershell scripts on a server.  These policies will help scripts from violating the rules.  There are six different policies:

Restricted
     This policy is the default policy set when Powershell is activated..  With Restricted, you cannot run an entire script but can run individual commands.  This policy also blocks the execution of module files (.psm1), configuration files (.ps1xml), and profile scripts (.ps1)

AllSigned
     This policy allows scripts to run on a server.  However, all scripts and configuration files need to be signed by a trusted publisher, like Verisign.  If you run a script that hasn't been classified as trusted or untrusted, you will be prompted for credentials.  This is more secure but there can be bad scripts written that have been signed.

RemoteSigned
     This is the default policy in Windows Server 2012 R2.  If you download a script from the Internet, you will need a digital signature from a trusted source.  The benefit of RemoteSigned is that scripts created on local computers do not need a digital signature.  Similar to AllSigned, dangerous scripts can still be signed.

Unrestricted
     Unsigned scripts can run (this can be dangerous).  You will be warned when you start an unsigned script from the Internet.

Bypass
     This policy lets any script run and there are no warnings or prompts.  Bypass is helpful if you are calling a script from a command line or from out of Task Scheduler.  Do not use bypass when you are running an unverified script.  Bad things can happen.


Personally, I try to never use Unrestructed, Unrestructed, or Bypass.  However, you may find a need to use one of these settings.  Just make sure you know risks of each one.

Monday, March 19, 2018

"Can you see if my account is locked out?"

Greetings!

Have you ever gotten a call or email or trouble ticket asking for help with a user whose AD account keeps getting locked out?  At my current company, we had a rash of this happening.  We found this occurred when people changed their Active Directory password.  In these days of people being able to access work email or work Instant Messaging, it is important to make sure these folks are changing the passwords on their personal devices.

In some cases, we can look to the domain controllers to find out where the lock is occurring.  I found this handy script from Mike F Robbins blog site (http://mikefrobbins.com/):


#Requires -Version 3.0



<#

.SYNOPSIS

Get-LockedOutUser.ps1 returns a list of users who were locked out in Active Directory.

.DESCRIPTION

Get-LockedOutUser.ps1 is an advanced script that returns a list of users who were locked out in Active Directory

by querying the event logs on the PDC emulator in the domain.

.PARAMETER UserName

The userid of the specific user you are looking for lockouts for. The default is all locked out users.

.PARAMETER StartTime

The datetime to start searching from. The default is all datetimes that exist in the event logs.

.EXAMPLE

Get-LockedOutUser.ps1

.EXAMPLE

Get-LockedOutUser.ps1 -UserName 'mikefrobbins'

.EXAMPLE

Get-LockedOutUser.ps1 -StartTime (Get-Date).AddDays(-1)

.EXAMPLE

Get-LockedOutUser.ps1 -UserName 'mikefrobbins' -StartTime (Get-Date).AddDays(-1)

#>
 
 
[CmdletBinding()]
param (
[ValidateNotNullOrEmpty()]
[string]$DomainName = $env:USERDOMAIN,
[ValidateNotNullOrEmpty()]
[string]$UserName = "*",
[ValidateNotNullOrEmpty()]
[datetime]$StartTime = (Get-Date).AddDays(-3)



)
 
Invoke-Command -ComputerName (
[System.DirectoryServices.ActiveDirectory.Domain]::GetDomain((
New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext('Domain', $DomainName))
).PdcRoleOwner.name



) {
 
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4740;StartTime=$Using:StartTime} |
Where-Object {$_.Properties[0].Value -like "$Using:UserName"} |
Select-Object -Property TimeCreated,
@{Label='UserName';Expression={$_.Properties[0].Value}},
@{Label='ClientName';Expression={$_.Properties[1].Value}}
} -Credential (Get-Credential) |
Select-Object -Property TimeCreated, UserName, ClientName


When you run this script, you will be prompted for a user name and password.  This user name must have access to the domain controllers.

.\Get-LockedOutUser.ps1 -UserName 'mike1'

Not only does this script look for individual accounts using the -UserName attribute but you can leave off all the parameters and you will get a list of all the accounts, on the domain, that are currently locked out.

.\Get-LockedOutUser.ps1

I want to thank Mike F Robbins for writing a terrific script that has helped me many time.  I hope it can help you all, as well.

Mike

Monday, March 12, 2018

What Version of Windows Server Am I Using?

Greetings!

I have had occasions where I wanted to inventory all my servers and what version of Windows Server is running on those servers.  Larger companies can use System Center Operations Manager (SCOM) to get that information.  However System Center can be expensive and overkill for small to medium businesses.

In order to get the list I wanted, I used the following PowerShell script:
Import-Module ActiveDirectory

Get-ADComputer -Filter * -Properties OperatingSystem, OperatingSystemServicePack, OperatingSystemVersion | Where-Object {$_.OperatingSystem -like '*server*'} |

Select-Object -Property Name, OperatingSystem, OperatingSystemServicePack, OperatingSystemVersion



It is important to include the Import-Module command.  If the command is missing the Get-ADComputer command will not work and you will get an error. 

The output from the script will look like the following:



Name      OperatingSystem                    OperatingSystemServicePack           OperatingSystemVersion


-----     ---------------                    --------------------------            ----------------------

Server1   Windows Server 2008 R2 Enterprise   Service Pack 1                             6.1 (7601)

Server2   Windows Server 2008 R2 Enterprise   Service Pack 1                             6.1 (7601)

Server3   Windows Server 2008 R2 Enterprise   Service Pack 1                             6.1 (7601) 




This script displays the ease of using Powershell.  By using just a couple commands, you can pull the information you want.

I hope you find this script helpful.  Good luck and happy scripting.

Mike