Tag: Automatic

Automating Software Deployment /w Ninite – Improved!

It wasn’t so long ago that I wrote this article; http://www.justfen.com/post/18843356303/automating-software-deployment-with-ninite

It seemed quite well received, I actually had some tweets and messages about it :O!

Now, two weeks ago I came across the following post on Reddit;

Ninite Pro. There’s a powershell script on a Spiceworks forum that pulls all machines from AD, as the Ninite machine scan leaves a lot to be desired.

Really I thought? I best go check that out!

The scripts in mention are the following;

http://community.spiceworks.com/scripts/show/1376-ninite-updater-domain-update-part-1-powershell

http://community.spiceworks.com/scripts/show/1377-ninite-updater-domain-update-part-2-batch

http://community.spiceworks.com/how_to/show/2968

Just thought I’d point these out in a great upbeat passive-aggressive manner.

Imitation is the best form of flattery

Anyway, moving on swiftly!

What this post really is about, an improved version

So that’s what I worked on tonight whilst upgrading our AV systems.

So this is single PowerShell file, it has the following Pre-requisites;

  • It must be in the same folder as NiniteOne.exe
  • You have to set the variables and paths beforehand

As for where I’d like to take this script

  • E-Mail of the logs, in a more legible format
  • E-Mail of outstanding needed software
  • Possible input of parameters rather than setting variables

Rather than writing a new blog post for when I push one of these features, you’ll be able to follow them over at GitHub @ https://github.com/fenneh/NiniteSloth 


How to Send an e-Mail from Powershell

Thought I’d slam this up here considering I’ve written the little snippet for this (I say wrote, it’s no doubt in many places on the net)

This little bit of code has a lot of potential, it can be used to automate report sending, notifications, outputs of queries etc!

In time I’ll post some examples of how to use it, but if you’re just looking for a clear-cut way of how to fire an e-mail off, then here it is

This script utilizes the inbuilt Send-MailMessage cmdlet built int PowerShell V2.0, more information can be found at the following http://technet.microsoft.com/en-us/library/dd347693.aspx


Automating Software Deployment With Ninite!

So, as in a previous post you’ve seen, I was using PDQDeploy to push software out across our network.

Now, I’ve got to the point where I’m fed up of having to set up new tasks, packages, hacking .MSI’s, creating transforms for each deployment… So I came back to Ninite.

When I was first looking for a solution to our software patching woes I’d originally looked at Ninite, something like deploying a Ninite installer with a silent switch, this was quickly shelved… it seemed pretty unsupported and wasn’t the most robust of sounding strategies. Saying that, this was over a year ago so recently I decided to check them out again. In that time they’ve now released a very cheap PRO version which can now mimic the functionality of Linux’s apt-get -somewhat-.

This got me thinking about a few possibilities, so I set out to set up an automated software patcher using it by using a little batch script and some PowerShell to pull machines to deploy to.

The Plan

  • Automate software deployment
  • Generate a list of target machines to patch
  • Use PowerShell to generate this list from AD
  • Create a batch file and attach to scheduled task with some logging.

Pulling the data from AD

Now I went down a few routes for this, the first was using some of PowerQuest’s AD CMDlets but I was sure there was another method. My chosen one was to use ADSI.

So without further babble from me here’s the PowerShell script I used to generate a list of machines for Ninite to use to target

$NiniteADSearch=new-object System.DirectoryServices.DirectorySearcher([ADSI]‘LDAP://OU=The,OU=Computer,OU=Group,DC=My,DC=Domain,DC=Name’,’objectCategory=Computer’)

$NiniteADSearch.FindAll()|%{$_.Properties.name} | Out-File NiniteTargets.txt -Encoding Default

This lil script when run will pull a list of Machines from the OU you’ve set it to, and all the sub OU’s. As in my domain, all Desktops and Servers are in completely different OU’s, this wasn’t an issue.

The script will also output the result into a file called NiniteTargets.txt in the directory you ran it from using ANSI encoding (Ninite will bomb out without this encoding, and yes it took a while to find that out)

Plugging the results into a batch file

So you’ve managed to generate your list of machines, time to feed these into the Ninite Pro program.

This was simply done using the cmd line switches which are documented here.

My batch file looked something like the following;

set NiniteScript=D:NiniteNiniteMachineGenerate.ps1

set NiniteTargets=D:NiniteNiniteTargets.txt

set NiniteCache=D:NiniteNiniteCache

set NiniteLog=D:Ninitelog.txt

powershell.exe -command %NiniteScript%

NiniteOne.exe /updateonly /remote file:%NiniteTargets% /disableshortcuts /disableautoupdate /cachepath %NiniteCache% /silent %NiniteLog%

ECHO

So what does this batch file do?

  1. Will only update currently installed apps
  2. Will generate and feed list of target machines in from the NiniteTargets.txt file generated by PowerShell script
  3. Will disable shortcuts and auto updates
  4. Will cache the installer/patch files to selected directory
  5. Will install updates silently and log the results to selected log file
And that’s about it, the result of this is an automated patching system when you set the batch file to be run as a scheduled task.
A word to the wise though, you may want to try playing around with NiniteOne.exe manually before just doing this, it’s still relatively new and you don’t want to be screwing up a big deployment now do you ;)?
I hope this helps some admin out there, especially those with a pretty tight budget.

Automating Windows Updates via Group Policy

A little bit of background information for this one. In the company I work for, we tend to patch everything, it’s a fine practice but when it comes to Windows Servers which we have close to 80 of, all of them are currently being updated by hand.

Now, other than being tedious and annoying it’s a pretty large overhead and consumes quite some time… never mind those which needed to be done outside of office hours.

So, my solution?

Well, the new year had come, I could see the horrific patch day Tuesday on the horizon (second Tuesday of every month) and decided to stamp my foot down.

First thing first, decide a time when this can happen, I opted for 3-5am where there are no Back-Up jobs going on, it’s outside of AV scans etc. This is now called the Update Window

Secondly, split a domain of servers up into groups based on different things, what ESX host they were on, what services run from them etc. One thing I kept in mind was to reduce any potential strain on our VM setups (Our hosts are a little crowded!) during the machine start ups the machines were distributed evenly between the two security groups.

Next thing was to construct the group policies and as a picture speaks a thousand words, here’s mine

GP

Once this GPO is published and applied the only other step is to exclude your 2 security groups (Romeo & Juliet in this case) from the default/predefined WSUS GPO’s

And that’s about it! 85% of our internal servers are currently auto-updating every Friday (You never know Microsoft and those damn extra hotfixes!)

TL;DR Make 2 security groups, exclude these from default WSUS GPO’s… copy the GPO above, publish, apply and enjoy.