Introducing Windows 10

Official announcement from Microsoft that the release date for Windows 10 will be July 29th.

Learn about all the reasons you’ll love the new Windows 10 – available as a free upgrade on July 29th. It’s familiar, comes with exciting new innovations like Cortana and the brand new Microsoft Edge browser, plus apps, Xbox and more. Learn more and reserve your free upgrade at

I’m a Backup Academy Certified Professional now!

I’m a Backup Academy Certified Professional now! And you?


Microsoft recertification controversy

Microsoft are shaking up their professional certification programmes yet again following the news that they were introducing the ability to sit exams at home using a remote proctor rather than needing to go to an examination center.

Now they have announced that recertifications can be done via ongoing study through the Microsoft Virtual Academy.

This announcement stirred up a hornet’s nest and many felt that this devalued their credentials as it would make it easier for people to cheat their way through recertification. On the Born to Learn site Ken Rosen put some of these questions and concerns to Larry Kaye the Senior Product Manager – Certification that made the announcement.

Ken was won over by Larry’s answers and I have to say that I was too.

VMwoes: Purple Screen of Death E1000PollRxRing

VMwoes Purple Screen of Death: VMware ESXi 5.5 host experiences a purple diagnostic screen mentioning E1000PollRxRing and E1000DevRx

VMware Purple Screen of Death

VMware Purple Screen of Death

VMware ESXi 5.5.0 (Releasebuild-1331020 x86_64] #PF Exception 14 in world 264638:vmm1:AGB-Dub IP 0x418039010c57 addr 0x0
cr0=0x80050031 cr2=0x0 cr3=0xa5a4f3000 cr4=0x42668
frame=0x4123a6f9cf30 ip=0x418039010c57 err=9 rflags=0x10206
rax=0x0 rbx=0x51 rcx=0x18
rdx=0x2 rbp=0x4123a6f9d3d0 rsi=0x1
rdi=0x4108a8348d40 r8=0x1 r9=0x1
r10=0x41122413a080 r11=0x4 r12=0x41001651cef4
r13=0x1 r14=0x4123a6f9d2e0 r15=0x4123a6f9d334
Code start: 0x418038e00000 VMK uptime: 60:02:35:05.115
0x4123a6f9d3d0:[0x418039010c57]E1000PollRxRing@vmkernel#nover+0xb73 stack: 0x8
0x4123a6f9d440:[0x418039013bb5]E1000DevRX@mkernel#nover+0x3a9 stack: 0x4123a6f9d658
0x4123a6f9d4e0:[0x418038f92164]I0Chain_Resume@vmkernel#nover+0x174 stack: 0x0
0x412306f9d530:[0x418038f79e22]PortOutput@vmkernel#nover+0x136 stack: 0x4108ff01f780
0x4123a6f9d590:[0x41803952ff58]EtherswitchForwardLeafPortsQuick@#+0x4c stack: 0x183c21
0x4123a6f9d7b0:[0x418039530f51]EtherswitchPortDispatche@#+0xe25 stack: 0x418000000015
0x4123a6f9d820:[0x418030f7a7d2]Port_InputResume@vmkernel#nover+0x192 stack: 0x412fc57f4a80
0x4123a6f9d870:[0x418038f7ba39]Port_Input_Committed@vmkernel#nover+0x25 stack: 0x0
0x4123a6f9d8e0:[0x41803901763a]E1000DevAsyncTx@vmkernel#nover+0x112 stack: 0x4123a6f9da60
0x4123a6f9d950:[0x418030fadd70]MatWorldletPerVMC0@vmkernel#nover+0x218 stack: 0x410800000000
0x4123a6f9dab8:[0x418038eeae77]WorldletProcessQueue@vmkernel#nover+0xcf stack: 0x0
0x4123a6f9daf0:[0x418038eeb93c]WorldletEHHIandlerft@vmkernel#nover+0x54 stack: 0x0
0x4123a6f9db80:[0x418038e2e94f]BH_DrainAndDisableInterrupts@vmkernel#nover+0xf3 stack: 0x2ff889001
0x4123a6f9dbc0:[0x418038e63e03]IDT_IntrHandler@vmkernel#nover+8x1af stack: 0x4123a6f9dce8
0x4123a6f9dbd0:[0x418038ef1064]gate_entry@vmkernel#nover+0x64 stack: 0x0
0x4123a6f9dce8:[0x4180391a32d3]Power_HaltPCPU@vmkernel#nover+0x237 stack: 0x418086e64100
0x4123a6f9dd58:[0x41803904e859]CpuSchedIdleLoopInt@vmkernel#nover+0x4bd stack: 0x4123a6f9dec8
0x4123a6f9deb8:[0x418039054938]CpuSchedDispatch@vmkernel#nover+0x1630 stack: 0x4123a6f9df20
0x4123a6f9df28:[0x418039055c65]CpuSchedHalt@vmkernel#nover+0x245 stack: 0xffffffff00000001
0x4123a6f9df98:[0x4180390561cb]CpuSched_VcpuHalt@vmkernel#nover+0x197 stack: 0x410000008000
0x4123a6f9dfe8:[0x418038ecde30]VMMVMKCall Call@vmkernel#nover+0x48c Stack: 0x0
0x418038ecd484:[0xfffffffffic223baa] vmk_symbol_MFSVolume_GetLocalPathf@com.vmmare.nfsmod#
base fs=0x0 gs=0x418046000000 Kgs=0x0
Coredump to disk. Slot 1 of 1.
VASpace (00/12) DiskDump: Partial Dump: Out of space o=0x63ff800 l=0x1000
Finalized dump header (12/12) FileDump: Successful.
Debugger waiting(world 264638) -- no port for remote debugger. "Escape" for local debugger.

Apparently it is a known issue with the particular release of the VMware ESXi 5.5 hypervisor we use on just one of our host servers. It has since been patched, but we went with the workaround as there wasn’t a huge number of virtual machines to modify.

The workaround is to replace the E1000 network adapters with the VMXNET3 adapters.

There is further information on regarding this bug Purple Screen of Death caused by E1000 adapters and RSS (Receive Side Scaling).

Know it Prove it – Identity and Access Management

Know it Prove it

100% completed with 2 days of February 2015 (and the challenge) to go.

Moving TempDB to a new location.

We had a process running on a particular SQL server virtual machine which was causing the TempDB file to grow exponentially and as a result caused the C: drive to run out of space. In this case the best solution was to move the location of the TempDB from the default location to a new location on the very large second Virtual drive.

The process is pretty straightforward.

Firstly locate the current file path of TempDB.
SELECT name, physical_name AS CurrentLocation
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');

Secondly perform the actual move with the following code. Modify it to choose new locations appropriate to your system.
USE master;
MODIFY FILE (NAME = tempdev, FILENAME = 'E:\TempDB\tempdb.mdf');
MODIFY FILE (NAME = templog, FILENAME = 'E:\TempDB\templog.ldf');

Cannot RDP to a Windows Server 2008 R2 virtual machine

A quite mystifying issue with one of Citrix test machines was escalated to me this morning. The member of staff whose role it is to configure new test environments on the Citrix servers Skyped me to say that he couldn’t RDP to the machine but could access it via the vSphere client and could I please take a look at it and see if I could work out what was going on.

It was in a hell of state and I suspect that he’d had a good go at fixing things himself but had made matters much worse. The Remote Desktop Services role had been uninstalled for a start! Not that that would have actually made much of a difference as RDP for Administration would still be available without that role installed.

From the command line I ran the following two commands.

netstat -a -o | findstr 3389

The first was to display all the active TCP and UDP ports on which the computer was listening and then find the string 3389 which is the default RDP port number, the second command displays information about Remote Desktop sessions on a server. Neither returned any result.

I then restarted the Remote Desktop Services service.

Checked Remote Desktop Session Host and then at that point realised that RDS was no longer there. Reinstalled RDS and configured it to point at the license server again. A redundant step in terms of resolving the issue, but an important one in restoring the server back to full functionality.

Disabled the Windows Firewall completely.

From elevated command prompt I ran the following two commands.
sfc /scannow
regsvr32 remotepg.dll

I thought about checking Group Policy to ensure that nothing silly had been configured that would have denied RDP connections.

To do so would involve opening up the Group Policy Editor locally and then expanding the following.
Computer Configuration – Administrative Templates – Windows Components – Remote Desktop Services – Remote Desktop Session Host – Connections.
Allow users to connect remotely using Remote Desktop Services (enable or disable)

But the issue was more fundamental than that as I could see that the port itself wasn’t open.

Then decided to check whether the correct port number was assigned to the Remote Desktop Services and using information from this knowledge base article I checked the port number associated with RDP in the registry.

  • Ran regedit and opened the following registry subkey:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Remote Desktop server\WinStations
  • Located the PortNumber registry entry.
  • Saw that the port number 3390 had been assigned.
  • Changed the port back from 3390 to 3389.
  • Saved the change, and then closed Registry Editor.

Tested RDP from my laptop and it worked.

Job done.

This strikes me as being a deliberate change . There is security advice out there that suggests changing the default port to something else, but I don’t believe that it offers a great deal of security and in this case was a massive pain. Also I can’t think who would have made this change.

ESXi 5: Suppressing the local/remote shell warning

Using the SSH shell is a pretty efficient way to get things done on ESXi 5.x, but annoyingly it is disabled by default. Enabling the ESXi shell is simple enough to do.

But having enabled it means vSphere will show a warning message ESXi shell for the host has been enabled and in the host view the host is shown with a yellow warning exclamation mark. If you’re like me you’ll want to enable the shell but not have the warning always showing.

Suppressing the warning is pretty straightforward. In the vSphere client select the affected host and then click the configuration tab. Open up Advanced Settings and click UserVars from the menu tree and scroll all the way down to the UserVars.SuppressShellWarning setting. Change the value from 0 to 1.


Find large vmware.log files

Since upgrading to ESXi 5.1 some time ago I’ve seen the logfiles for some of our virtual machines grow truly massive, like over a gigabyte in size massive.

Removing the logs isn’t too difficult simply either vMotion the VM or shut it down entirely and then power up again. Both methods result in a new log being created allowing the old log to then be deleted.

The difficulty is in finding which VMs have generated huge log files, especially when you have well over a hundred virtual machines.

The following is a simple one line piece of code to show the 10 biggest logfiles, it can be amended accordingly to show a greater number.

cd /vmfs/volumes/; ls -lhdS [A-Z]*/*/vmware.log | head -10

To prevent that datastores are shown twice, once by name and once by id, it is limited to only show datastores starting with a capital letter, all our datastores start with an upper case letter, you may have to adjust the command to fit your particular environment.


POODLE Attack – Disabling SSLv3 in Internet Explorer via Group Policy

The POODLE attack (which stands for “Padding Oracle On Downgraded Legacy Encryption”) is a man-in-the-middle exploit which takes advantage of Internet and security software clients’ fallback to SSL 3.0. Further details on the nature of the attack can be found here.

SSL 3.0 will be disabled in the next releases of all the major web browsers, but until then the following steps can be taken to protect clients in your company through disabling SSL 3.0 and enabling TLS 1.0, TLS 1.1, and TLS 1.2 for Internet Explorer in Group Policy.

You can disable support for the SSL 3.0 protocol in Internet Explorer via Group Policy by modifying the Turn Off Encryption Support Group Policy Object.

  • Open Group Policy Management.
  • Select the group policy object to modify, right click and select Edit.
  • In the Group Policy Management Editor, browse to the following setting:
    Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Advanced Page -> Turn off encryption support
  • Double-click the Turn off Encryption Support setting to edit the setting.
  • Click Enabled.
  • In the Options window, change the Secure Protocol combinations setting to “Use TLS 1.0, TLS 1.1, and TLS 1.2”.
  • Click OK.

Note Administrators should make sure this group policy is applied appropriately by linking the GPO to the appropriate OU in their environment.

To achieve the same in Mozilla Firefox is not possible centrally via Group Policy but can be done on an individual basis through installation of the SSL Version control plugin.