FacebookTwitterDiggGoogle BookmarksRedditTechnoratiLinkedinRSS Feed
Pin It

vCAC 6.0 Installation Gotcha

For any of you out there planning on installing the IaaS components of vCAC 6.0 onto a Windows Server 2012 machine, there's a small gotcha that will keep you from installing. In Windows 2012, they have .Net in the operating system as a component so that you don't have to install it separately, but the version they give you is 4.5.1.

vCAC IaaS component won't install... I mean it won't even start to install. There will be no error given on the screen, but when you go into the Windows Application event log, you'll see an error referencing .Net.

How to Fix it, or Prepare in Advance:
1. Check your windows installed patches for patch #2881468
2. If that patch exists, uninstall the patch
3. Reboot the Windows server

Huge thanks goes to Jeff Baylor and Sky Cooper at VMware Professional Services for finding the issue, discovering the fix, and sending it on to me to post here.

Potentially an Unpopular Article: Creating the Necessity for Automation in Other Teams

It's been a very busy few months with VMworld in San Francisco as well as Barcelona. The best part for me, by far, was being able to participate in all the discussions on automation and self service. I ended up noticing some pretty strong themes in the discussions, and the main things I took away were:

  1. Virtual Infrastructure teams know that they need to automate and provide self service to end users for requesting abstracted resources (virtual infrastructure) to remain the technical partner of the business -- Great!
  2. Not all of the teams that virtual infrastructure depends on feel the same need to use abstracted layers or automation -- Not so good...

This is a problem. If it only takes 2 minutes to provision a virtual machine (the virtual infrastructure part), but 5 weeks to do everything else, we've still failed at delivering a service to the business that is in line with their expectations. With unacceptable service like that, we continue to drive end users to the public cloud. For more on the risks of end users going around the IT team to get resources, check out one of my other articles: Why Your Business Doesn't Think It Needs You

Let's remember the history of infrastructure a bit here, because we're going to talk about some things that might make me unpopular with some people. Years ago, resource requests were taking an excessively long time to procure fulfill. In a worst case scenario technical teams needed a new machine then to rack and image it. To keep up with the business needs, infrastructure teams moved to an abstracted platform (a hypervisor) which allowed them to quickly create, tear down, and automate the provisioning of resources. The implementation of hypervisors were propelled primarily through an onslaught of requests to support the business. Let's keep this in mind as we move forward.

Here's where I might become unpopular--in all the sessions I sat in, the feedback was that the networking team is the choke point at which machine provisioning process slows. I also heard that because their processes aren't abstracted and automated, or aren't automated using a tool that infrastructure teams can utilize, infrastructure teams aren't able to fully automate the infrastructure provisioning process. This, and lengthy approval processes, are the largest reasons why a resource request goes from taking 2 minutes taking 5 weeks.

I would argue that it doesn't matter that you can't automate the networking. Going back to our history from above, until people can't keep up, they don't automate. To that point, sometimes something has tom come along to create that necessity to automate. Below is the track that I suggest taking in order to bring the most change to your organization:

1. Implement a self service catalog that automates the creation of virtual infrastructure. I might be so bold as to suggest VMware's vCAC
2. Within your self service and automation solution, create or enable a the concept of a lease which limits the amount of time that an end user can have a resource for. vCAC allows you to do this, as well as determine if users should be able to extend those leases on their own, with approval, or not at al. This is going to help ensure that resources that aren't being used get torn down-- increasing the efficiency of your physical infrastructure. 
3. create a manual task for the networking team for them to go off and complete their actions in whichever way they deem necessary. You can even make it so that they can simply enter the information into the approval in your provisioning tool to make life easy.

This approach is going to add value and immediately improve your organization's physical resource utilization but also, it's going to cause churn as machines will be provisioned and destroyed with higher frequency.

Automated provisioning processes ensure that the infrastructure teams aren't feeling the impacts of the increased VM churn but the result is that the networking team will start to see issues in the form of people having to sleep at their desks to keep up. The sheer volume of requests, just like the infrastructure teams experienced before compute abstraction layers, will push them to look for a solution to abstract and automate as well. Luckily, products like NSX exist to do just that. Your moves should the go as followed:

4. Encourage abstraction and automation within the networking team
5. Call out to the networking automation from the infrastructure self service and automation solution
6. Configure your self service and automation system to require an approval by the networking team before the resources get delivered to the end user. This gives them the ability to confirm the settings that the resources were given while they are working out potential kinks and getting comfortable with the idea of automating their processes.
7. When they're comfortable, take off the training wheels by removing the networking team approval.

The fact of the matter here, is that networking is undergoing the same transition to abstraction layers that infrastructure went through years ago. The driving force in both situations is to support the business by delivering services they require within an acceptable time frame. The difference is that the virtual infrastructure teams have had a few years head start. That head start is at a detriment to the teams like networking as public vendors have started to come out with offerings that your end users can access. The pressure on these teams will continue to build until they adopt a more efficient model of fulfilling requests, and it's in your organization's best interest to build that pressure early in attempt to minimize the risk to your organization of end users attempting to get a faster, not necessarily better, service in an unregulated public cloud.


FIXED: VMworld Keynote Showing the Next Cloud Provisioing Platform

I know, I know... this is really late to the party. The fact of the matter is that I do have a day job, but this is simply too exciting to skip over. For those that didn't make it to VMworld, Carl and Kit bantered back and forth while showing the next version of cloud provisioning, including vCAC and VMware's application provisioning tool. If you haven't already seen it, you can check it out at the link below. The coolest one is the day 2 session which demos the new provisioning platform.


This new product has some really exciting features added to it, and you can be sure that we'll be talking about them soon here on vCACteam.info.

Why Your Understanding of the vCAC Development Kit (CDK) is Holding You Back

You may have noticed a change to the vCACTeam.info site within the past few weeks. Yes, the colors are different but there's also no longer any references to "Customization"--instead the sections of the site talk about "Extensibility". This site, does not, and probably will not focus on customization. We would much rather show you how to extend the tool out to be able to get the functionality you need while maintaining upgrade paths.

There's a huge difference between "Customization" and "Extensibiltiy", both from cost, upgrade process, and required skills. Below is a little table I created to compare the two topics to hopefully illustrate the differences.

Extensibility Customization
  •  DOES NOT require the CDK. It can, however use an INCLUDED workflow designer tool
  • Requires the CDK license
  •  More likely to survive an upgrade, or easily be converted to the new version
  •  *Potentially* breaks the upgrade path (depending on what is done)
  •  DOES NOT require that you code in .Net
  •  Requires .Net experience

Below are some examples of functionalities that would fall into the two categories

Extensibilty Customization
  • Calling to a 3rd party system (IPAM, LDAP, CMDB, ITSM, etc, etc) through PowerShell, vCO etc.
  • Gathering additional information on a custom "day-2 operation" (the list of actions to the right of the VM).
  • Creating a complex naming convention for provisioned machines
  • Adding a NEW workflow stub (this usually doesn't happen as 6 stubs come out of the box which cover most of the needed change states)
  • Sending emails at specific times throughout the machine life cycle
  • Making you coffee in the morning
  • Calling vCO workflows

You'll notice that the functionality in the left side column is very robust. You can do a ton without the CDK, and to reiterate--NOTHING on this site requires you to have the CDK. The fact of the matter is, is that you're really selling yourself and your organization short by thinking that everything that doesn't come out of the box requires a CDK license as well as .Net coding skills.

Give me your thoughts/questions on the topic on Twitter @vCACTeam. Either way, let's get this cleared up in the community!