I know the issue was discussed here: Edit Virtual Machine failing with "[Error code: 42000 ] - [Error Msg: Infrastructure service provide... and it was said, that it would be rosolved in the newest iteration of vCAC. Back at 6.0.x, as was suggested in the thread, I have changed the locale on the Web Server, wich has helped remediating the issue. The problem was no longer reported.
Today I face the error using the following configuration:
- vCAC 6.1 (09.09.2014), all IaaS Servers have german locale (standard at our company)
- Myself using Firefox with en_us as the prefered language
- A vCAC user on Firefox with german locale (standard)
With 6.1 came the localized GUI (we primarily use a german version of Firefox and german locale settings on all IaaS servers) and edit Requests submitted by a user fail with the error 42000. The https://localhost/WAPI/elmah.axd log shows the error "String was not recognized as a valid DateTime". After the 6.0->6.1 upgrade I still left the en_us locale set on the Web Server and thought, that maybe the issue persists, because the user is accessing the portal with a german version of Firefox. I myself use firefox too, except with the english language pack and there are no issue with editing. So what I did was to change the locale on the Web Server back to german, but this did not help in remediating the issue.
That only thing that helped is, that the user changed his Firefox browser language setting to use en_us as preferred. I've changed my browser version to german again and got the same issue as the user, that is edit failing with error 42000.
Is anybody else facing the same problem and could maybe help with finding a permanent resolution?
Can confirm that I am getting this too when using Chrome. I am just testing it in Firefox as I type.
I can't believe this bug still exists. It's literally a show stopper for us. Users will not adopt the system if they have to make workarounds when editing a VM.
I'll open a SR later and report back
I can confirm the problem with german browser language in vCAC 6.1.
Is there already a result from the SR?
The chap that I spoke to was very helpful and confirmed that it looked like a regression of the bug.
If you can, open an SR with VMware because they need to know that this is a problem.
As more of a permanent work around we changed the format of the short date in the iaas service accounts profile to the US format...
It's a bit of a shame that the bug still exists for people with localised copies of windows but I guess there is nothing we can do about it!
That is from memory so I will double check tomorrow... but it should be fine.
Thanks for the fast response!
I also did that… I found the Workaround here: http://elasticskies.com/vcac-6-edit-vm-failing/
But no improvement in my Environment.
If you did something else, please keep me updated.
I have just hit this issue so thanks for all the info detailing the workaround. Just for the record, my environment is 6.1 and my IaaS server was running with the United Kingdom (en-GB) locale. Changing this to US and altering the reg sShortDate entries for the default and service account user (that all the vCAC services run under) and then restarting the server was required to fix the issue for me.
I have raised an SR with VMware and I suggest everyone who experiences this problem to do the same.
We applied the workaround suggested at http://elasticskies.com/vcac-6-edit-vm-failing/ and discovered this wasn't enough to remedy our problem. (Incidentally, the referenced post contains some valuable info on how to validate this problem using the "elmah" ASP.Net debugging tool. A very helpful and welcomed discovery for sure )
Turns out we needed to change the web browser Language Settings or Preferences to English (United States) [en-US] at the "client" end as well in order to synchronize calls being made to the IaaS WAPI Application after applying the changes to the Registry and Region and Language Settings in Control Panel. This was confirmed using both Chrome and Internet Explorer browsers. Not sure if this corresponding workaround is required on all vCAC 6.X instances, but our version is 6.1 Build 2041200 and this resolved our issues immediately.
Hope this helps..
Opened an SR with GSS on this. We just received confirmation that this is to be resolved in vRealize Automation Version 6.2
thank for your detailed reply...
We had installed the Version 220.127.116.11 2077124 (now rolled back) and plan a second update now.
The Version 6.2 is not an option for us wen need the VMRC...
With a new VMRC implantation?
If you have further Informations... I will be happy about them.
I had the same issue with dutch (internet explorer) clients and a English iaas server. Editing a IAAS VM wasn't possible. I had to change the culture under ".NET Globalization" of the WAPI to Auto Detect
Interesting Arthur. Is this the only workaround you applied or did you also need to change the browser Language Setting on the client end to use "en-us" preferred and/or "sShortDate" Registry Changes on the IaaS Server end as well?
The IAAS server allready had the en-US settings, so the shortdate was correct in the registry (checked it). CHanging the browser settings wasn't realy a option.
Having the iaas server with a shortdate of M/dd/YYY and the IIS website .Net globalization on Autodetect, seems to fix it for us.