After attending the "Future of IT" Google hangout in September, I was asked to give a quick summary on what 2014 may hold.
So without further ado..
I believe in 2014, we will see an increased demand for - and usage of - hybrid clouds, especially among SMEs who are trying to avoid large investment on private clouds to accommodate high demand, short term projects.
End user computing will play an ever larger role, with BYOD becoming even more viable for businesses, including those with strict data controlled environments. This will make use of the many mature products now available such as Horizon Workspace.
Network virtualization will gain more traction but only in some enterprise and highly specialised SME environments - NSX is a good example of this. We may well see an increasing amount of SMEs adopting virtualization in either a more serious manner or start looking at it for the first time now that local host storage is becoming a reality, cutting out the need for potentially expensive storage solutions.
Feel free to comment and let me know if you agree or disagree with my thoughts!
2013 has been an amazing year for me – I was awarded the vExpert title, I’ve taken and passed my VCP5-DCV, VCAP5-DCA and VCAP5-DCD and spoken at the London and UK national VMUGs. I’ve attended my first VMworld and spent countless hours in the lab and on study, generating about 30 blog posts. All I can say is that it’s been a truly blessed year.
After two and a half years working as a Senior Infrastructure Analyst for a global insurance company, the time has come for a change! For a while now I’ve felt that I’ve outgrown my current role and that perhaps it was time for a change. I have worked with some really excellent people on my team while here, and I’ll definitely be sad to say goodbye to some of them! I’ve had the opportunity to work on some huge-scale environments and highly complex systems – all of which allowed me to learn and grow in ways not possible in a “normal” size environment.
I’ve had the opportunity to get to know a lot of really good guys through Twitter, VMUGs and VMworld – including several of my colleagues-to-be at Xtravirt. Gregg Robertson, Daren Woollard and the rest of the Xtravirt guys are a real testament to the company and so when Gregg asked if I’d be interested, I jumped at the chance to interview for a role there – despite being quite far along the process for 2 other roles and having an offer on the table.
In the end, I chose to join Xtravirt because I believe they are market leaders for virtualisation and specifically cloud consulting, and they continue to learn and strive for excellence as a matter of course, which fits closely with how I approach my work. I am really excited to be joining and for the chance to be part of a company that I feel I can make a difference for, as well as developing and learning myself. While it may sound cheesy (or even a little obsequious) Xtravirt has a bit of a family feel to it, and that too makes it a very attractive place to work.
So there it is – I will be starting in January as a Senior Consultant for Xtravirt and I am really excited to get my teeth into the role!
Finally, I have to thank my amazing wife Ruth for supporting, encouraging and believing in me, and for her patience and understanding while I went through the process that ended here.
In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.
The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution. However, I can envisage situations (similar to mine) when the SSO administrator account is not used for a long time and expired – that causes headaches.
To modify the SSO password policy log onto the vSphere Web Client as the SSO admin (admin@system-domain for 5.1 or [email protected] 5.5) and select Administration, then Sign-On and Discovery > Configuration. Select the Policies tab – you should see the default config:
Click edit and set the password policy as required. This only applies to SSO users (i.e. those in the System-Domain or vSphere.local domains). To set the password to never expire set the Maximum Lifetime to 0. IF you chose to do that, I’d beef up the complexity of your password policy to include upper, lower, numeric and special characters and increase the length from 8 to 13.
Similarly, you can edit the lockout policy which by default will lock you out if it has 3 failed attempts within 24 days. It will lock you out for 15 minutes. Setting the lockout time to 0 forces a manual unlock by an SSO admin.
The second option seems preferable to me (and Anthony and Grant) – that is to add some AD users or groups to the SSO administrators group. To do this, again log in as an SSO admin and select Administration, then Access > SSO Users and Groups, then the Groups tab. Select “__Administrators__” and click on the add principals button below. Select your AD domain from in the Identity Source field and search for your required user or group. Add them and click OK. Now those users, or group members have the ability to log on and reset or unlock the SSO admin account. AD accounts are obviously subject to your AD password policy, but can be reset independently of SSO and therefore don’t require you to use some command-line kung-fu to unlock.
Today I found out that in vSphere 5.1 the SSO administrator account (admin@system-domain) has a password that expires after 365 days. See KB2035864:
vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for admin@system-domain.
In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation)
By default, vCenter Single Sign-On passwords, including the password for [email protected], expire after 90 days.
Following KB2034608 to reset the admin@system-domain I came across an interesting error:
There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ). My preferred route is to have it enabled but locked down.
Note: VMware use the term “ESXi Shell”, most of us would term it “SSH” – the two are used interchangeably in this article although there is a slight difference. You can have the ESXi Shell enabled but SSH disabled – this means you can access the shell via the DCUI. For the sake of this article assume ESXi Shell and SSH are the same.