Tag: Deployment

How to Prestage a VMWare VM in Windows AD via PowerCLI

Recently when working on our deployment of machines, we hit a few brick walls.

The main issue was how long it takes for a template from vSphere to be cloned, then join a domain. The delay is whilst you wait for the machine to Sysprep and VMWare to do its magic.

At first, I was dirty and put a delay in our creation scripts before doing anything else to the machine, but this just didn’t cut it.

So, I moved on to pre-staging the VM in our Windows AD, which meant things such as Group Policies and Security Groups would be applied on its very first boot which meant one less reboot before our virtual machines were ready to have applications deployed to them.

Here’s the function which can perform said wizardry… it’s pretty simple but doesn’t seem to be very well documented anyplace.


Disabling SSL2.0 & Others for IIS7.5 for PCI! /w Powershell

=========================================================

Just to note, this has since been revised. You can see the changes @ http://justfen.com/post/22121613280/pci-iis7-5-beast-vulnerability-donendusted

=========================================================

So, recently been touching up some of our setups for PCI compliance, one of the things we failed on was the fact SSL2.0 and other Protocols were enabled on our IIS7.5 sites.

This had to be implemented into our Web Server deployment scripts and was done with the following;

function Set-IISSecProtocols {

$protopath = “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols”

& reg.exe add “$protopathPCT 1.0Server” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$protopathSSL 2.0Server” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$protopathSSL 3.0Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.0Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.1Server” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$protopathTLS 1.2Server” /v Enabled /t REG_DWORD /d 00000001 /f

}

And for the Ciphers;

function Set-IISCiphers {

$cipherpath = “HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers”

& reg.exe add “$cipherpathNULL” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathDES 56/56” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 40/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 56/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC2 128/128” /v Enabled /t REG_DWORD /d 00000000 /f 

& reg.exe add “$cipherpathRC4 40/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 56/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 64/128” /v Enabled /t REG_DWORD /d 00000000 /f

& reg.exe add “$cipherpathRC4 128/128” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$cipherpathTriple DES 168/168” /v Enabled /t REG_DWORD /d 00000001 /f

& reg.exe add “$cipherpathAES 128/128” /v Enabled /t REG_DWORD /d 00000001 /f 

& reg.exe add “$cipherpathAES 256/256” /v Enabled /t REG_DWORD /d 00000001 /f

}

To have these changes you must remember to restart the machine, yes REALLY. I actually fell for the trap, so thought I’d share!

And yes, it’s a little dirty but it works!


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.

Mozilla Firefox 10 ESR

For those out of the loop… Firefox 10 ESR is Mozilla’s attempt at trying to recoup some of their market share by catering (I use this word very loosely) to enterprise companies by now offering a deploy-able and supposed customizable Firefox package.

Now, personally, I’ve been deploying Firefox for some time by using Frontmotion .msi packages, those guys are great and will pack up a tidy .msi in no time which can then be edited in Orca to disable features such as Auto Update etc…

But none the less, Mozilla are giving it a whirl despite 7 months ago telling enterprise customers to “Drop Dead” (Source).

So, without further ado here are the gory details of Mozilla’s attempt to leap back up on market share.

Mozilla will offer an Extended Support Release (ESR) based on an official release of Desktop Firefox. Releases will be initially maintained for nine release cycles (currently 54 weeks, which is close to the target of 52 weeks the proposal is attempting to hit), with point releases coinciding with regular Firefox releases.

To permit organizations sufficient time for testing and certification, the ESR will have a two cycle (12 week) overlap between the time of a new release and the end-of-life of the previous release. This will allow organizations who control updates (e.g. have disabled automated updates) to Firefox to qualify and test against Aurora and Beta builds for twelve weeks leading up to the ESR, and an additional 12 weeks to certify and transition to a new ESR. Organizations that rely on Firefox’s built-in updater may be limited to a transition period of 6 weeks, dependant upon how the ESR releases are maintained.

The proposal can be read here.

Now, whilst I don’t totally agree with what is proposed I’ve gone ahead and deployed it to all non-developers within my organization.

Hold on a second, where can you download it?

Ah, well this was the very very first issue I had. Even though it had been released, finding the actual download was quite an issue even with my expertise in google-fu.

You can find the downloads tucked away on the Down…wait no, the FAQ page (I must confess since the first draft of this post there is now a download page located here)

Wait… it’s an .exe, enterprise??

Yeh well… uhmm.. :/ I don’t know

And, how to deploy?

Personally, I used PDQDeploy to deploy it, but you can use any of the usual methods of PSEXEC, GPO etc to get it done.

One thing you’ll want to know is the silent switch which is simple /s or I believe -ms this will allow you to deploy it and to have it install without user interaction.

Also from what I can gather is it can install over the top of previous Firefox installs, but this made need a little more testing!

Best of luck!


Free Windows Software Deployment – PDQDeploy

Now, this was one of the first issues I ran into during my foray of being a SysAdmin.

We were a small shop, about 80 desktops and most if not all software deployment was done by hand. This meant we had lots of outdated software and a sizeable overhead when an end user would request an updated to X,Y,Z.

Now, as a somewhat of a start up and being new in my role, I wasn’t one to quickly recommend the most expensive solution. Instead, I decided to give PDQDeploy a whirl. It proved a decent hit.

And why not? It ticked every box we needed

  • Simple software deployment
  • Can be scheduled
  • Post-deployment reports

And still to this day for pushing out Firefox, Java, Shockwave, Reader, Flash (Damn you!), iTunes updates and other small little programs.

When this is tied hand in hand with a Secunia mailing list it’ll give you a pretty good head start on when systems will need to be patched.

So if you’ve been tasked with restructuring your software deployment process or just looking to reduce some workload, I’d suggest you give PDQDeploy a whirl.

Damn… This reads like a sales post.