SkyCoop's Accepted Solutions

I don't believe you are actually searching Customization Specs, you are seeing residual specs you typed in previously in some form that used the same backend name.
Check the release notes: VMware vRealize Automation 6.2.1 Release Notes , not sure if this is what you are experiencing? After upgrading to PSC 6.0, a 400 Request error appears when you access ... See more...
Check the release notes: VMware vRealize Automation 6.2.1 Release Notes , not sure if this is what you are experiencing? After upgrading to PSC 6.0, a 400 Request error appears when you access the default tenant URL, https://FQDN_VA/vcac, because port 7444 is no longer valid in SSO registration in the vRealize Virtual Appliance* The error message, Trying to access remote SSO on host vra-va-hostname.domain.name and port 7444, but the returned host is vra-va-hostname.domain.name and port 443 appears on the Virtual Appliance when you try to re-register the Virtual Appliance to the upgraded PSC 6.0.
The health monitors rely on services being up before passing traffic to a particular node, the services can't start until the traffic is being passed to the first node that is starting up.  I typ... See more...
The health monitors rely on services being up before passing traffic to a particular node, the services can't start until the traffic is being passed to the first node that is starting up.  I typically put in a record in the hosts file on both the virtual appliance and the IAAS web nodes that point to the VIP name to the local IP, then the stack can start up with the health monitoring left in place. If you do this on the virtual appliance, make sure you put the hosts entry outside of the VAMI GENERATED (or something like that) comments, as this is rebuilt each time the appliance restarts. -just saw the certificates are loaded on the load balancer - I don't do that, just pass the traffic through. (Think it is layer4-performance in F5 terms)
From the manual - format is bad, but page 11 of the IaaS Configuration for Virtual Platforms PDF Order of Precedence for Custom Properties When the same property exists in more than one sou... See more...
From the manual - format is bad, but page 11 of the IaaS Configuration for Virtual Platforms PDF Order of Precedence for Custom Properties When the same property exists in more than one source, a specific order is followed when applying properties to the machine. You can add custom properties that apply to provisioned machines to the following elements: n A reservation, to apply the custom properties to all machines provisioned from that reservation n A business group, to apply the custom properties to all machines provisioned by business group members n A global or local blueprint, to apply the custom properties to all machines provisioned from the blueprint n Build profiles, which can be incorporated into any global or local blueprint, to apply the custom properties to all machines provisioned from the blueprint n A machine request, if you are a business group manager, to apply the custom properties to the machine being provisioned The full order of precedence for custom properties is that any property value specified in a source later in the list overrides values for the same property specified in sources earlier in the list. The order is shown in the following list: 1 Build profile 2 Blueprint 3 Business group 4 Compute resource 5 Reservations 6 Endpoint 7 Runtime Any runtime property takes higher precedence and overrides a property from any source. A custom property is marked as runtime if the following conditions exist: n The property is marked as Prompt User, which specifies that the user must supply a value for it when requesting a machine. This requires that the machine requestor customize individual characteristics of each machine, or gives them the option of doing so when a default value is provided for the required property. n A business group manager is requesting a machine and the property appears in the custom properties list on the Properties tab of the Confirm Machine Request page. Custom properties in reservations and business groups may be applied to many machines so they should be used carefully. Their use is typically limited to purposes related to their sources, such as resource management, line of business accounting, and so on. Specifying the characteristics of the machine to be provisioned is generally done by adding properties to blueprints and build profiles. Each blueprint of any type can optionally incorporate one or more build profiles and thereby inherit the custom properties in those profiles. Build profiles are especially useful for applying common sets of properties for specific purposes to a wide range of blueprints. For example, your site might want to add a second disk to, customize Microsoft Remote Desktop Protocol behavior for, and enable Active Directory cleanup for a wide variety of machines. If a build profile with the necessary properties is created, it can be incorporated into all of your blueprints, local or global. When creating and managing build profiles, a fabric administrator can load a number of predefined property sets to add several related properties all at once, instead of one by one.
To update a property from vRO, vCAC 6.1 - Update a Custom Property from vCO - Realize.net To update an array of properties from vRO (this builds on the previous post) - vCAC 6.1 - Generic Blue... See more...
To update a property from vRO, vCAC 6.1 - Update a Custom Property from vCO - Realize.net To update an array of properties from vRO (this builds on the previous post) - vCAC 6.1 - Generic Blueprint With vCO - Realize.net Those posts don't meet your use case, but shows you how to update properties from vRO, which hopefully helps out? You will find somethings can't be updated in the BuildingMachine state, or rather can be updated, but will be ignored. Network Profiles is one that comes to mind, updating VirtualMachine.Network0.ProfileName in building machine occurs after the IP information has already been allocated during the request.
The relationships require you to select the child value, even if there is only one option. There was a time in 5.2 with the optional web portal you could install, that would select the child if t... See more...
The relationships require you to select the child value, even if there is only one option. There was a time in 5.2 with the optional web portal you could install, that would select the child if there was one present, but that has gone away. What I would do is use a vRO workflow in the building machine state and have it set the CustSpec value based on the property that drives the value of the others and pass that back to vRA. It is a pretty easy operation and a good opportunity to play with vRA -> vRO if you haven't done anything with it before. I wrote a blog post on how to update a property in vRO and pass it back to vRA, there is a follow-on post that has a more complex update that allows you to have a generic blueprint that updates the cloneFrom and cloneSpec properties based on what OS is selected. http://www.realize.net/2014/10/vcac-6-1-update-custom-properties-vco/
My understanding, based on working with the product since January 2011 - The original functionality was all based on agents, the agent was installed to do one thing, and it could only do one thin... See more...
My understanding, based on working with the product since January 2011 - The original functionality was all based on agents, the agent was installed to do one thing, and it could only do one thing. It connects to the manager service via SOAP, and requires installing a dedicated agent for a particular type of endpoint. The DEM communicates with the web server via REST, it does not maintain a personality like an agent, but pulls down the required workflows at runtime. This allows you to update a given workflow one time centrally, and all the DEM's will run that new version next time they execute it. There was an architectural decision after the DEM was introduced, that new functionality would be written into the DEM type platform and originally DynamicOps was talking about moving the agent functionality into the DEMs (never happened).  So you will see things like Amazon EC2, physical provisioning, calling vRO, etc. are executed by the DEM Workers, but the original core functionality of the product (vSphere, Hyper-V, etc) have associated agents that execute that work.
ProfileName = Network Profile (not range) as you discovered, you are able to specify different ranges within a given profile so that if there are non-contiguous blocks of IP's (already allocated,... See more...
ProfileName = Network Profile (not range) as you discovered, you are able to specify different ranges within a given profile so that if there are non-contiguous blocks of IP's (already allocated, existing servers, etc). You can use the VirtualMachine.Network0.XXXX block to set the static IP, but you probably have associated the specific network profile with the port group in the reservation. If you plan to assign a static IP, make sure the reservation has the network port group selected, but no profile assigned there. Could you create two network profiles, and associate range a to one, range b to the other, do not select a profile in the reservation, and use your original drop down example pointing to the two different network profiles?