Category Archives: vRealize Automation 7.x

Error – Blueprint component Machine – Correct the highlighted errors

Soon after changing vRA IaaS service account password and reflecting it at all the required places using VMware KB and we realize that all is well.

But we end up with some strange issuses like the one I am going to be explaining here. This was in vRA 7.3, all was working fine. But as per Enterprise Password policy (even for service account 🙁 ) they ended up changing service account password. as I said in first paragraph, reflecting this is an easy task as long as we follow steps in KB 2099949 but what about Custom property values stored in Property groups which are encrypted.

what we started facing was, at the time we try to submit a request form for majority of blueprints, we started facing this error.

Blueprint Component Machine – Correct the highlighted error


if we then go and look into component machine form, we don’t see any field highlighted, but error still persist.

this is when, go into Blueprint design, explore attached Property Groups, among those property groups, there would be one/more of the custom properties with encrypted value (like password field), just go ahead and retype values for those encrypted fields. Save the blueprint again. And raise a request form again, make sure you fill in all the required fields and submit the form. Error’s gone. 🙂


Rename vSphere datastore which is being used as Storage Path in vRA 7.2

Just for curiosity sake, This morning I have decided to see how vRA managed machines behave when I rename corresponding datastore name.

Let’s say I have a vSphere cluster being used as Compute Resource in vRA, and this cluster is being backed by a datastore named ‘datastore1’, and there are set of VMs residing on this datastore and are being managed by vRA 7.2, obviously in this case there’s a reservation in place which has got ‘datastore1’ selected as storage path.

Now, as I have just renamed datastore1 to a new name ‘NewDatastore1’ and triggered manual Inventory Data Collection. if I check back in reservation, the storage path name has been changed as per new name of the datastore.

and the corresponding database entries got updated without throwing any errors, which proves that rename of the datastore even if it is being used as StoragePath in vRA gets handled by quite well by vRA. a Simple data collection updates relevant entries.


How to reset administrator@vsphere.local account password in vRA 7.x?

Have you forgotten your administrator@vsphere.local account password which you created at the time of initial configuration of your vRA 7.x environment, here’s how you reset it.

1) Login into Master vRA Appliance VAMI using appliance root user
2) go to vRA Settings -> SSO
3) in password fields for administrator user account, enter new password that you want to set (Please remember you don’t need old password at all), also confirm the new password in confirm password field
4) Save settings
5) wait for 10 to 15 minutes (Once it comes with Settings saved successfully message), go into Services tab and wait until you see all the services reporting Status as Registered, periodically refresh the page using button provided

if this is a single node vRA appliance based environment, please skip to step 10) directly.

6) now proceed to second vRA node, login in VAMI
7) Navigate to vRA Settings -> Cluster
8) Provide the FQDN and credentials of the master node and hit join the cluster
9) Again give it about 10 to 15 minutes and check status of all the services to become Registered

– Please repeat step 6 to 9 for all the additional vRA appliances in vRA nodes cluster.

10) Clear cache in the browser and try to login with administrator@vsphere.local to default tenant

your administrator account password has been reset successfully.

Additional bits to consider:
If administrator@vsphere.local account was used at places like configuring vCAC plugin in vRO, make sure you update password at all those places.


vRA 7.x Infrastructure Tab reporting Server Error 401 – Unauthorized: Access is denied due to invalid credentials

the reason I am creating this blog post is purely because the message was mis-leading but the actual reason was different fot this error in Infrastructure Tab.

One of the customer retported that they cannot see IaaS-Service regsitred in vRA VAMI -> Services, it’s being reported as blank.

at the same time in vRA portal, under Infrastructure tab Server Error 401 – Unauthorized: Access is denied due to invalid credentials was being displayed.


Further checks in IaaS web server host where ModelManagerData repository was residing, IIS Application Pool called RepositoryAppPool was stopped.


attempt to start it was failing with some weird error message.

Service account password was not modified and should be working without much trouble.

That’s when something interesting got pointed in Repository.log

[UTC:2017-04-07 02:27:49 Local:2017-04-07 10:27] [Error]: [sub-thread-Id=”1″  context=””  token=””] Failed to start repository service. Reason: System.Security.Cryptography.CryptographicException: There is not enough space on the disk.
at System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr)
at System.Security.Cryptography.X509Certificates.X509Utils._LoadCertFromBlob(Byte[] rawData, IntPtr password, UInt32 dwFlags, Boolean persistKeySet, SafeCertContextHandle& pCertCtx)
at System.Security.Cryptography.X509Certificates.X509Certificate.LoadCertificateFromBlob(Byte[] rawData, Object password, X509KeyStorageFlags keyStorageFlags) at VMware.Cafe.RegistrationData.ConvertCertStringToCertificate(String certRawData) at DynamicOps.Repository.Runtime.CafeClientAbstractFactory.InitializeFromDb(String coreModelConnectionString) at DynamicOps.Repository.Runtime.Common.RepositoryRuntime.Initialize().

and that certainly poited to right direction now, a quick look on system drive of the IaaS Web server host revelaed that there’s no space left on c: drive, and further investigation into this, and realized that IIS logs which were piling up since last 2 years were occupying 31 Gb all together, keeping just last 30 days worth log files and moved rest of the files on a different shared location was the first activity carried out.

Further steps taken are as below:

  1. Restart of the IaaS web server node after making enough space on c: drive
  2. restart of vcac-server in vRA appliacnes

These two actions have made things come back to normal.