As usual VMware magnanimously offers to provide extended support for a ‘small’ purchase price.
“In the event you are unable to upgrade before the End of General Support (EOGS) and are active on Support and Subscription, you have the option to purchase extended support in one year increments for up to two years beyond the EOGS date. Visit VMware Extended Support for more information.”
If support is just a best-case scenario and you can stomach going it alone (with Google searching) then Technical Guidance with be available for another year until September 19, 2020.
“Technical Guidance for vSphere 5.5 is available until September 19, 2020 primarily through the self-help portal. During the Technical Guidance phase, VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes unless otherwise noted. For more information, visit VMware Lifecycle Support Phases.”
Technical Support is always a good option to have and for all of you knowledge seekers it is a great way to learn the nuances of VMware products. See my previous post Tech Support is Not a Dirty Word for my take.
What is VMUG Advantage? It is a more advanced membership for all VMware admins, VMUG members, and those who want to learn VMware technologies and receive other benefits and discounts as well. It includes many of the best technologies from VMware with a 1-year license. It is the single best and least expensive way to get access to VMware technologies to teach yourself in your own lab environment. If you haven’t heard of VMUG Advantage then this post is for you.
Here is a comparison of memberships:
Please click the image to read the full benefits list and get yours today. While you are at it please check out your local VMUG Group. VMUG groups meet 3-4 times per year and sometimes more. You can learn so much about emerging technologies from interesting speakers and sponsors. You will also meet interesting people going through the same trials and successes while using VMware products. Click Gainesville VMUG to check out my local group.
This week I am sharing a very helpful PowerCLI script to vMotion a vm from one SSO domain to another SSO domain. I shamelessly borrowed this script from Romain Decker’s site Cloud Maniac. The original script was very good and functioned well. I just took it a step further and added some functions to customize it for our environment. These functions are: Get-SourcevCenter, Get-DestvCenter, Ask-VMNameForMigration, Ask-DCForMigration, Ask-ClusterForMigration, Choose-StorageForVMMigration. The names of each function should explain their use. Essentially you will need to edit the script to customize some of these functions for your environment.
I have used it dozens of times and it works flawlessly with one exception. If your EVC modes don’t quite match between vCenters there may be some vms that cannot be vMotioned while powered on. Just arrange for a downtime and try again with the vm powered off. It will work well. This sure beats downloading a vm to your desktop and then uploading it to the new vCenter environment. If you need any explanation or help with modifying this code to fit your environment please feel free to comment.
Since I work in a multiple vCenter environment, it is nice to have a function that allows for a connection choice when running a PowerCLI script. The Get-vCenter function has an array of all the vCenters I potentially might connect with to run a PowerCLI script. This array is presented in a numbered format that allows the script user to choose the vCenter they want to use for the rest of the script. You can make the array as large or small as you want. It will dynamically create a numbered choice next to each vCenter. It is simple but comes in very handy.
Caution: Like all code you download from the internet, please understand and modify the code accordingly to prevent unforeseen production problems. Also known as career-altering events.
After reading the title of this article I’m sure you’re saying, ‘You can’t change VCSA hostname. You have to redeploy.’ That is what I was told and all the documentation I have read says you have to redeploy. Well it is not true. With that said here is your warning about mucking with the VCSA configuration. Don’t do it! Unless you are working in your test environment and you came across a ‘workaround’ that you wanted to try. I still wouldn’t recommend using this ‘workaround’ in your production environment without extensive testing and upon recommendation from VMware Support.
Why did I need to change the hostname in my test lab? I applied 6.5 U1 to the VCSA in my test lab. I then checked the VCSA and saw that the hostname was changed to ‘localhost’ and AD authentication was broken. It also broke ssl certificates. I was getting ready to redeploy the VCSA when I came across this ‘workaround’ and I gave it a try. It worked great.
Change VCSA 6.5 U1 Hostname with vami_config_net
The ‘workaround’ is really a built in utility called vami_config_net. The full name of this utility is configure-network command-line utility. Here is what the utility looks like in use with relevant configuration names blacked out.
Option # 3 will prompt with ‘New hostname’ and show the current hostname. I made this change in my test lab and it did not require a reboot to start working. However, I made this change after the VCSA had lost domain trust. I had to take the VCSA completely out of the domain, delete the computer object, and join it to the domain again. The VCSA is working wonderfully once more.
If I had tried to change the ip address it would have failed without changing the dns to reflect this before making the change. In this very limited use case vami_config_net worked because I changed the hostname back to the original name. I would not have faith in using this utility to just to change from one hostname to a completely different hostname until I have tested further.
One of the less annoying things I encounter on a daily basis is the wrong default domain on my vCenter appliance. Changing the vCenter default domain is necessary in my environment because the empty-root domain is default. Our main domain where all of our user accounts reside is a sub-domain of the empty-root domain. That means that you can’t just login with your normal credentials without using the domain\username or [email protected] formats. This isn’t a large problem but anything that speeds up my day is always appreciated.
It turns out that this is a known problem for users in a child domain where the vCenter has been upgraded from version 5.5.0 to 5.5.0b or later. In my case the users can login still if they put the domain prefix as part of their login. I just don’t want to have to worry about that especially for those in our enterprise that can’t figure out how to login by using a domain prefix.
To change the behavior of the identity source, the default domain can be changed on the Single Sign-On (SSO) server from the domain that was created during the upgrade.
Windows-based Single Sign-On (SSO)
Connect to the machine that is running the SSO instance. Create the defaultdomain.ldif file containing this information using a plain text editor:
Note: Replace example.com with the desired default domain from your environment. Contents of .ldif file should be terminated with “-” .
As an Administrator, click Start > Run, type cmd and then click OK. Run C:\>ldifde command to confirm that the ldifde tool is available. This list returns a list of available commands. If the tool is not present, install it by running this command:
This week has been non-stop worrying about Hurricane Irma. All I can say is ‘Go Away Irma’. You’re cramping my style! Apparently it was not necessary to plan for disaster recovery until a week before the strongest hurricane in recorded Atlantic ocean history is going to hit. All that other planning can just be thrown away. Let the fire chiefs take over and ring the alarms. I could use more drama in my life. (Extreme SARCASM). At this point I still don’t know if I will be working this weekend or not.
I would love to hear from you if you’re having some interesting challenges in regards to disaster recovery. On a positive note, I am so glad we have VEEAM. I can’t imagine facing a hurricane and having to use our old backup software. for needed restores. VEEAM’s byline was ‘It Just Works’ and there has never been more truth in advertizing.
There will be lots of prayers over the next week and I will be among those praying for safety and for rescue for all people affected by hurricanes this season. Here’s hoping that we can get back to the normal workplace dysfunction I am used to on a daily basis.
Amazon Web Services and VMware have finally launched their much anticipated VMware Cloud on Amazon Web Services. What does this mean for traditional VMware shops? In my opinion it means that the ease of exploring the cloud for enterprises has become much more likely to happen. In other words this will accelerate the move to the cloud for vSphere deployments everywhere.
VMware Cloud on AWS Key feature
The ability to manage applications across your private-on-premises cloud and AWS becomes seamless. The ability to see your Amazon vSphere clusters in your vCenter just like any other cluster is awesome. This is what I have been clamoring for and I can’t wait to try this.
Hurdles to overcome using VMware Cloud on AWS
I hope that this will also mean that I can go out and purchase Amazon Web Services through VMware which is already a trusted partner for our enterprise. At my enterprise we have been exploring the possibility of moving some services to the cloud but we are running into issues with our legal team and the Amazon Web Services contract. Amazon has been very resistant to changing any of the legal language that our lawyers are insisting upon. The result has been that we are stuck in limbo. I hope to explore this further in the coming months and will update here what I find.
Do you have to generate more than a few ssl certificates as part of your day-to-day job? Would you like to script it? I have a script for you. This PowerShell script has proven itself very indispensable when we had to replace all of our sha1 certificates. (Thanks Google!) I hope you find this script useful and if you do, please leave feedback.
Note: You can always modify the script to accept a list of fully qualified domain names if you need to produce a large quantity of certificates.