Dales Diary

End of the road

admin — Wed, 14 Mar 2012 13:17:47 +0000

So i’ve been writing this blog for a number of years now most of it inane dribble but there are a few posts that you lot on the web seem to find useful, however it is time that I stop writing for this blog as my career direction is now changing. I have always written this for sysadmins and internal IT support staff because that is what I was, now however I am moving on and into a role with a consultancy company so i shall from now on be sitting on the other side of the fence.

This url also now no longer reflects my direction so i am migrating the useful posts to a new url which will go live shortly vhorizon.co.uk . So thank you for all the hits and the comments over the years and hopefully you will make your way across to vhorizon.co.uk where I shall continue to blog about all things virtual.

Blackberry a dying platform

admin — Mon, 05 Mar 2012 14:27:10 +0000

The consumerization of IT and BYOD (bring your own devices) is here its been on its way for sometime but now its here and IT have to deal with this fact.
Smartphones and tablets are now a part of everyday life whether your an apple evangelist or android fanatic or even windows phone friendly they all far outway the abilities of phones or even desktops from just a few years ago. They are the true plug and play devices of the consumers world. In addition to technology people’s attitude towards telecommuting and working away from the office is also changing. Just a few years ago working remotely to most people meant being handed a blackberry for email and sent on your way with the url of the Citrix farm. Now things are completely different.

Has anyone got or used a blackberry recently, blackberry’s are still widespread in the enterprise but they are quickly being replaced with smart phone/tablet devices. What is the reason for this, well if you have used one recently what did you use it for I bet it was either making a phone call or checking your email. Browsing the web with one is tedious at best their app store is very limited and the design of most devices makes any kind of remote desktop / vdi impossible unless you have the patience of a saint and the eyes of a hawk.

What about sysadmin management, at least you would need a besx server and another windows licence to purchase and dear lord do not touch the version of java installed on the server unless you like you blackberry users phoning you.

Consumers/staff now have a vast array of plug n play technology in their hand bag or trouser pockets, if you want your phone to do something that’s not in its initial design then there’s more than likely an app for that (as they say), which is more than likely free or low cost and will require little technical knowledge to get it working.

So back to my point in question blackberry have fallen way behind and have made very little if any progress in the last few years coupled with their recent large scale outages blackberry in my opinion are doomed. Consumers are used to pretty interfaces and intuitive design now, if you mentally put your favourite smart phone ui next to the usual blackberry one the winning argument is plain to see. Whilst blackberry management and security is still far more granular than smartphones and tablets there are very good options for an IT department to deploy in order to mitigate risk if the activesync policies and features are not enough.

I see many companies migrating away from blackerry and alot of comments from sysadmins saying they cannot wait to get the last blackberry off their system so they can decommision the server. Are smartphones really less secure than blackberry’s, possibly but in todays world it can be mitigated and is mostly a moot point. IT must now adopt a different approach its not “how can I secure the remote device” anymore it should be “how can I secure my application against a remote device” which is true whether you are talking about vdi/virtualization or teleworking.

RIM were unable/unwilling or just didn’t see that the market is moving on, so I am quite convinced that as a company they will not survive because of the consumerization of IT.

Restart vnxe unisphere webui

admin — Fri, 17 Feb 2012 11:42:43 +0000

Has your unisphere login page got stuck and you cannot login to the unisphere environment to administer your box. There is an ssh command that you can use either through native ssh to the box if you have enabled it through the service options or by attaching the mini serial cable to the unit and using hyperterminal or similar to login to it.

Once logged into the vnxe interface in order to restart the unisphere environment enter the command svc_restart_mgmt and hit enter this will restart the webui which will take several minutes to complete.

This operation only restarts the webui and does not affect the storage in anyway so you can safely perform this action during production hours.

Vnxe write cache temporarily disabled

admin — Thu, 26 Jan 2012 16:52:42 +0000

If you’ve tried to update the vnxe firmware and the update has failed (usually around the 21% mark). Then you will find that the write cache will not be re-enabled until the software update has completed sucessfully. Now when i’ve had this issue emc have stated that its because of a hung process but I found that restarting storage processors do not cure the issue. What I did to resolve the error was to put both storage processors in service mode and then pull the power out of both sp’s.

Once the vnxe is completely bereft of power the plug both back in and wait for it to boot, take the sps’s out of service mode and re attempt the software update. It should go through without any further issues.

Its essentially the old turn it off and on again solution.

Vmxnet3 driver crash in ESXi5

admin — Wed, 25 Jan 2012 13:47:48 +0000

Hi all,

I’ve had a couple of occurances of this where a server 2003 R2 vm will seemingly just loose network connectivity. Attempting to ping either in or out will not work. Whilst sometimes powering off and on the vm will resolve the issue it wont stop it randomly happening again (naturally during production hours).

I’ve noted that there is a VMware kb on the issue (which I found after i’d resolved the issue) however it states that it occurs when you have jumbo frames enabled within the guest vm. This however is not the case in my experience.

To resolve this issue just add another vnic to the vm using either the e1000 or vmxnet2 and remove the vmxnet3 vnic the re-enter the vm’s ip information in the newly added card. Another choice would (as a #lonvmug colleague of mine had discovered) be to reinstall vmware tools and reboot the vm Link . Reinstalling the tools is the best bet but I was unable to do that as the vm in question was a terminal services box so I hot added another vnic to avoid rebooting and loosing the disconnected sessions.

There will be some cases where you will need to reboot the vm afterwards such as network sensitive app that cannot handle a short amount of network disruption.

Renew your Citrix fundamentals 6 licence

admin — Wed, 11 Jan 2012 19:54:30 +0000

So you’ve managed to install citrix fundamentals 6 and keep running with it for a year, now you get those lovely emails saying that you have to renew your licences for it.

Once you have logged into your mycitrix account and reallocated your new licence and downloaded the .lic file what do you do next.

1/ Log into your citrix fundamentals server and open the Citrix quick start applet.

2/ Click on the licencing menu item on the left hand side then hit the blue hyperlink that says “Add Citrix licences”.

3/ Point the dialogue box at your downloaded licence file and allow xenapp to install the file.

4/ At this point you will notice that the licences are cumulative *i.e. if you have 30 licences last year and have just installed the renewal licence for another 30 then 60 licences will be reported within the console with the approaching renewal date displayed rather than the renewal date (next years date).

5/ At this point you will need to open the services.msc console (start\administrative tools\services) and stop the “Citrix Licencing” service.

6/ Once stopped (assuming you are using server 2008 R2) Navigate to c:\program files (x86)\citrix\licencing\my files\ and MOVE the old licence file out of the directory. Its important that you leave all the other files within the directory such as the citrix.opt and the citrix_startup.lic. If you are unsure of which licence file to move you can look at the licence file with notepad and within the top line is the expiry date of the licence file (in US format).

7/ Once the old licence file has been moved out of the licence directory, you can start the “Citrix Licencing” service within windows and check to make sure it displays the correct number of licences and days remaining. If you still had the citrix quick start applet open you will need to close and reopen it as more than likely the licence page won’t work until you do so.

next london vmug 2012

admin — Thu, 15 Dec 2011 18:49:27 +0000

The next London mug (virtual machine user group) is open for registration with presentations and demos from renound VMware blogger and vendors. Registration is free for this #lonVMUG on the 26th january at the london chamber of commerce.

Visit for more information.

Moving exchange mailboxes with powershell EMS

admin — Mon, 28 Nov 2011 21:31:57 +0000

To move a single exchange 2007 mailbox within powershell from one database to another you would use the following command.

Move-mailbox –identity “%username%” –targetdatabase “%DB%”
This would be the equivalent of right clicking on a user object with the exchange console and choosing move mailbox. However the real power of powershell comes into play when you want to move multiple mailboxes from one database to another. In order to do that you would combine the move-mailbox cmdlet with get-mailbox. A simple usage would be something like.

Get-mailbox | move-mailbox –targetdatabase “%DB%”
This would move all mailboxes on the exchange server to the target database, however you may find that you already have a few mailboxes on the target database or you want to move users from a specific database to another database (if you had 3 databases for example). For this you could use:

Get-mailbox –database “%sourceDB%” | move-mailbox –targetdatabase “%DB%”
This would ensure that all mailbox from the source database are moved to the target. This process is not quick however as it opens each mailbox and creates another at the target then moves messages and folders across to the target. If you specify more than one user (or like above feed the move-mailbox mailboxes as multiple variables) then exchange will move 4 mailboxes at a time. During the move the mailboxes being copied will not be available whilst they are transferred.

You can also check what mailboxes reside on the database by typing get-mailbox –database “%DB%” you can use this before you move the mailboxes to get a good idea of how many you are moving, and you can also use it after the move-mailbox action has completed to ensure that non have been missed.
If the move-mailbox action errors on any particular mailbox (usually it will be because of corrupted mail items in the mailbox) then the mailbox move will not complete for that mailbox. This will leave a complete mailbox for the user on the source database and a partial mailbox on the destination. However after a few minutes exchange will delete the partial copy and you can try the move again. If the move fails because of corrupted items in the mailbox then you can force the move to occur by using the –baditemlimit variable if you simply must copy the mailbox, setting the limit at 1000 should cater for all really.
Move-mailbox –identity “username” –targetdabase “%DB%” –baditemlimit 1000

How to virtualize a Domain Controller

admin — Sat, 05 Nov 2011 21:47:58 +0000

First off a domain controller is always a scary thing to p2v but it can actually be a fairly straightforward process to complete.

In our network our DC’s also have other roles and services installed on them which made the easiest and proper way of just creating a new DC within the virtual environment then demoting and removing the old physical one rather difficult. So p2v was really our only option.

If you follow these instructions then you wont go far wrong with p2ving your domain controller.

1/ Investigate your domain controllers services and see if you also have any transactional databases on there as well or anything that may be sensitive to consistancy (such as SQL/Oracle/backup software or AV).

2/ Write down the services that are associated with any DB’s or picky software you may have.

3/ Run the vmware converter standalone install on the domain controller but choose the advanced install (client-server) and select only the agent to be installed.

4/ Once the install has completed Reboot your DC into DSRM mode by furiously hitting F8 at the appropriate point of the boot process.

5/ Input your DSRM Adminstrator password (remember at this point there are no domain accounts available on the DC).

6/ Open up the services.msc tool and stop and disable those servers you have listed previously as sensitive to change (db’s etc).

7/ Run the vmware vCenter Converter Standalone client on your own laptop or whatever you use to do p2v’s with.

8/ P2v the DC in the normal way running through the wizard (If you get the old multiple connections are not allowed message try inputting the IP of the DC instead of the DNS name or the other way round depending on what you have done first).

ii/ One thing you will need to think about if is your DC points to itself for primary DNS resolution then the conversion will fail and in the export logs you will see something similar to this “Found dangling SSL error”. Change the server you are converting to point to an alternative DNS server that can resolve your ESXi servers and vCenter addresses.

9/ When the p2v process has completed from the ViClient make sure your vNic’s are disconnected from the network (so when the vm is powered on it wont be able to talk to the production network).

10/ Uninstall all the vendor installed helper drivers and apps etc, (hp/dell/IBM nic drivers and diag utils etc) and configure the networking also reenable and set the services back to automatic or whatever the previous state of the services were (SQL DB’s AV\Backup software etc).

11/ shutdown the physical DC and also the virtual DC.

###WARNING AT THIS POINT THE PHYSICAL DC MUST NEVER EVER BE CONNECTED BACK TO THE PRODUCTION NETWORK EVER AGAIN###

12/ Reconnect your vm to the production network and power it on.

13/ When its booted give it a few minutes to calm down and then login and check the following

Event Logs (its handy to check the old ones pre p2v as well) just to make sure your not panicing about an error or message that existed previously.

Check replication by creating an object in AD (a user for example) on the other domain controller and check that it is replicated to the newly vm’d DC
Delete the newly created object and check that it is also deleted on the other DC.

Run DCDIAG and NETDIAG and pay attention to any errors or informational messages you may receive.

Check your backup software interface I know for sure that Backupexec disables the job and you have to run through the edit settings menu and reselect the drives/folders you want to backup.

Then all you need to do is monitor the situation and just periodically check the event logs etc for oddities.
The last and most important job of all is to go into your server room and decable the old physical server (for the sake of a couple of minutes this could save you hours of heartache if a well meaning tech powers the DC back on again by accident).

vSphere 5 database support

admin — Mon, 31 Oct 2011 22:34:54 +0000

When considering which backend database to use in a new installation of vSphere 5 you have the following options:

Microsoft SQL Server 2005 or 2008 32 bit or x64 patched to the latest SP release
Microsoft Sql Server 2008 R2
Oracle 10g R2 , 11g R1 or 11g R2
IBM’s DB2 9.5 or 9.7 patched to the latest versions
SQL Express 2008 is also supported and bundled with vsphere

It is naturally recommended to house the vSphere database on a seperate server for added resiliency however with most deployments you can quite happily install the database component on the same server as the vSphere installation (whether this is physical or running as a vm). It is also worth checking which databases vmware update manager or other add-ons support if you intend to install these on the same server and of course consider what you in-house support is happiest managing (its no good installing vSphere using an Oracle database if the support staff have only ever administered SQL).