So the SQL account password expired for your View Composer. Bummer. This must mean you’re here because you’re seeing and googled error messages like this in event Viewer under VMware View Composer:
“[Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user ‘<user>’
and this in the %PROGRAMDATA%\VMware View Composer\Logs\vmware-viewcomposer.log
NHibernate.ADOException: cannot open connection —> System.Data.Odbc.OdbcException: ERROR  [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user ‘<user>’. Reason: The password of the account has expired. ERROR  [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user ‘<user>’. Reason: The password of the account has expired.
Good news space heroes, there’s a really well documented VMware KB procedure on how to recover from just such a scenario. Other things to try before doing this procedure:
In the recent case of quickly fixing this that I encountered, we changed the password to the same password and that still didn’t work. Following this procedure of re-creating the SviWebService.exe.config worked. This is because the password is encrypted and stuffed into the config file using the certificate data. The basic steps that are in this article are:
Are you tired of opening the vSphere console on a desktop that wouldn’t be re-composed only to find this?
Waiting for background programs to close. Force log off.
Me too. These registry keys will force the closing of open applications. I had to post this just so I would have quick reference to it in the future. Import these registry keys into your golden image and say goodbye to desktops that won’t shut down. When I say shut down you say HOW FAST. That’s right.
Windows Registry Editor Version 5.00
Actual things I’ve said:
“So, you have 32 different pools for 400 people?”
“So, you have one full virtual for every employee worldwide?”
When I’ve said these things or things like it, I usually get the Nicholas Cage look back, like “DUDE I KNOW…It’s not like I had a choice”
It seems that plenty of folks have had the same problem of pool sprawl due to application compatibility issues, or things they were unable to script or work around. Having been in delivery in the virtual desktop space means that I have seen and lived with the problems of a stateless desktop environment, most of which can be overcome with some time, energy and willingness to script. Most of these obstacles are profile related, and can be easily mopped up with third party tools, but the focus of this post is what happens if we stay inside the VMware product suite without any third party extras. So the main painpoints that remain apart from profile and application setting abstraction are:
What ends up happening to most organizations is that we end up getting bacteria-like applications which cause admins to create separate pools or put a user on a full virtual. The VDI admins often times end up getting torqued at the “fringe apps” that are not central to the core business but still need to run in the virtual desktops. This is usually due to the fact that there are more use cases in a department than are initially guessed. A good example is when a Marketing department is actually 4 different use cases rather than 1 due to crazy one-off app requirements. Along those lines, these are some of the problems I’ve seen with some of the fringe “problem child” applications:
Let’s take a look at an image from the vmware.com AppVolumes page which clearly illustrates the difference between a locally installed or streamed from the network or remotely hosted application.
While AppVolumes won’t kill the bacteria in your swimming pool, it will most certainly allow you to clean and clear up your View pools and pave the way to a single golden image dream with instant and simple application delivery along with much cleaner and safer update methods with a faster rollback. It will mean that the only legitimate need to create a new pool is for resource differences in the VM containers themselves, and the golden images themselves will mostly likely have no apps installed locally in it. This is absolutely FANTASTIC. Under the covers, what’s really happening is that the applications and settings are being captured to a VMDK which is mounted to the capture machine, then the application is installed to it. It’s sealed, and then disconnected and hot added to multiple VMs simultaneously. The craziest part of this whole method of updating the installed applications means that you almost never have to kick a user out of their VM. However in the software as is, you have to unpresent the AppStack, then re-present the updated version during an update, so it’s a not an entirely seamless AppStack update procedure, but it’s a heck of a lot better than dealing with a recompose that impacts more departments than it needs to due to the use of a COE pool (common operating environment) which I and others preach when using stateless desktops use cases. Once I get some hands on with the product I’ll know more about the update procedure and will write about it for sure, but apparently it’s been a pretty hard to get hands on even for partners.
So what does this mean looking forward? It means that you can crack open a can of Happy New Year 2015, and start fresh. REALLY. Fresh. It’s the opportunity to start with a clean slate and keep it clean as a whistle, while maintaining persistent user installed applications, per department applications, and one off applications. Not to mention if you own Horizon Enterprise, you will get AppVolumes for free out of the gate! Cheers to that!
I’m going to try to start a new App Volumes themed blog post series for those like myself waiting for Cloud Volumes to become GA. The following are some of the topics I’d like to write on. If you’d like to hear one of them, please sound off in the comments, it’s a good source of motivation. : )
During the preparation for my VCDX-Desktop, I had the pleasure of meeting a lot of awesome folks. One of them shared this clip with me and felt it appropriate to share. It is 10 minutes long, but totally demonstrates why requirements which turn into moving targets can totally change iterations of a design.
I have been on a residency for the past few months in a 1,200 user VDI deployment for a customer in the financial industry, to aid in finishing the VDI rollout portion of the project which had already stalled several times. Yes, this means that as a VCDX-Desktop my first gig was in fact physically deploying zero clients and helping users with random enterprise applications and MS Access databases. Not exactly the high life, but a little bit of humble pie never hurt anyone. Eventually, I came to see this as an awesome experience that delivery consultants seldom get, which was the opportunity to see the VDI project all the way through to the end rather than simply the initial config, set up a few pools and then high fiving the team on the way out the door.
Here are my big picture cautions and updates in my design philosophy updates in no particular order. Please remember that as no two businesses are identical, neither are their VDI requirements. It’s extremely difficult to generalize about VDI except that the requirements vary widely, so you can apply a grain-full-of-salt here depending on your use cases. Also, some of this isn’t news, just public reiteration.
VM Sizing/Golden Images/Windows Optimization
Enterprise Application Management
Systematic Rollout Plan
These are just some of the tips I’ve picked up on the most recent project that has spanned the last few months. I welcome any open conversation and fearless feedback on the manner, as civil disagreements most often lead to positive change for the better.
Good news! We’re near the end! This part is definitely the lowest stress part of the upgrade, so wipe that sweat from your brow and grab a lemonade.
Since in this series we didn’t upgrade vCenter or ESXi, there’s no need to upgrade VMware tools. However, if we had, this would be where we would update tools, followed by the VMware View agent in the VM.
Just like every other update, if you’re using Linked Clones, it’s just a golden image update and recompose. If you’re using full clones, you’ll need to deploy it however you usually deploy new software, GPO, SCCM, Altiris whatever.
Here is the next next procedure screenshots, not much notes here.
Waahooo! Look at that! They dun there rolled all the HTML, RTAV and vCOPS straight into the View Agent Binary. Upgrades that roll in feature packs are just dandy. Of note, make sure to select SmartCards if you require those, it’s the only option not selected by default. And then either recompose or script the update to your full clones.
Wowee! Look at that! We’re done! Hope this blog post series was informative, helpful and not too sarcastic sounding.
Every once in a while I get to take off the VDI fixer/architect hat and put on the fun-loving gamer hat. This was one of those occasions. This is an older video on View 5.3 that I just now got around to posting, I lost it on my harddrive for a while and didn’t have time to look for it. It’s truly amazing what you can accomplish with nVidia Grid cards, Apex Cards and PCoIP.