Tag: Windows

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.

PCI, IIS7.5, BEAST Vulnerability… Done’n’dusted!

As mentioned in a previous article, I’ve recently been trying to lock down our IIS servers a little bit more, mainly for PCI compliance.

On these ventures something was noticed, the enabled RC4 protocols were not actually working!

We ummed, we arrred to no result. After checking over Microsoft documentation, the problem became a little clearer.

It seems on Server 2008R2/IIS 7.5, simply setting the registry values for the ciphers to 1 wasn’t enough. They HAVE to be set to 0xfffffff or 4294967295 ;P

Something which was also noted was that TLS 1.1 and 1.2 hadn’t been activated, these also needed an extra registry key (Yep…)

So without much more jibberish, here’s the update Powershell functions/scripts to help aid you with making your IIS7.5 servers PCI compliant.

Now, that’s the ciphers and security protocols set up.

The last step to make your servers BEAST immune is to change the SSL cipher priority.

This is done by creating a GPO!

  1. At a command prompt, enter gpedit.msc. The Group Policy Object Editor appears.
  2. Expand Computer ConfigurationAdministrative TemplatesNetwork, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, click the SSL Cipher Suite Order setting.
  4. In the SSL Cipher Suite Order pane, scroll to the bottom of the pane.
  5. Follow the instructions labeled How to modify this setting.

It is necessary to restart the computer after modifying this setting for the changes to take effect.

The list of cipher suites is limited to 1023 characters.

See http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx for more indepth instructions.

The one thing to note for this is that the RC4 ciphers NEED to be at the top of this list as they are immune to the BEAST attack.

A great write-up of this by Steve Dispensa can be found over here http://www.phonefactor.com/blog/slaying-beast-mitigating-the-latest-ssltls-vulnerability.php

He even includes an example string for the cipher priorities!

But that’s that.. for now. If only we could move onto TLS1.2!

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 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


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.

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.