Automated Application Converter - Error 4390 (VIX Error: 3014)

[iainjo]

We've configured AAC for the first time and we're getting the following error message when we run through the wizard. We're just testing with one Win 2003 VM at the moment in order to prove the process, that machine added and configured fine.

VirtualMachine: VIX Error: 3014
Error 4390 controlling virtual machine: Failed connecting to image: 0x065b (LE:0000 XE:0bc6 in CVirtualMachineController::Create:89)

We're using AdminStudio 11.5 and the VM infrastructure is based around VMware vSphere 4.1.

We've run through the documentation and followed the configuration step-by-step. Following the errors we've run through "First Things to Check", all correct. We've then run through "How to Test a Virtual Machine" to the point of repackaging an application.

The error appears to relate to user credentials.

3014 – VIX_E_HOST_USER_PERMISSIONS
Insufficient permissions in host operating system.

The "Guest" username and password that we have entered under the "Machine Settings" are able to authenticate on the VM (domain account with local admin permissions). The domain isn't specified as documented, we've tried entering that just to be sure and still no joy.

That account (by virtue of a domain security group) has all the access requirements to the VM as documented.

Thanks.

[Evan_Border]

Can you post a screenshot of the AAC window that shows the entire log (the gray screen that gives a play-by-play of how far it got before failing out)?


For VMware vSphere 4.1 I suggest installing VIX version 1.10.3 on the AdminStudio machine. (I know the documentation says to install the latest version, but I've had instances where the latest version no worky)

Also: Your VM's in the VMware vSphere should be located at the root. I have not had luck creating a group within vSphere and having my VM's belong to it (it fails to control the machines, regardless of the rights I assign).

In vSphere, your role (that the ESX user belongs to) needs the following rights to the VM:

All Privileges - Virtual Machine - Interaction
* Acquire guest Control ticket
* Backup operation on Virtual Machine
* Console Interaction
* Create Screenshot
* Power Off
* Power On
* Reset
* VMWare Tools Install

All Privileges - Virtual Machine - State
* Create Snapshot
* Remove Snapshot
* Rename Snapshot
* Revert to Snapshot

http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q213407

***Also:
-Be sure that you can RDP to the VM and log in with the account that you are specifying. You must be allowed to log in interactively via RDP (the account needs to be in a group that is a member of the local Remote Desktop Users group.)

-The account must also have local admin rights on the VM.

-Be sure that group policy is not undoing stuff. Ex: I'm currently working in an environment where policy is turning UAC back on, thus the AAC is breaking.

-As a test, power-on the VM and immediately get eyes on it using the vSphere client and verify that it is getting straight through to the desktop without issue. Make sure that there is no login banner, CTRL+Alt+Del requirement, login prompt, UAC prompt (when Repackager is being launched), etc. Also make sure that the AAC Guest Agent (big gray window) appears.

[iainjo]

Hi Evan,

Thanks for the comprehensive response. I've attached a screenshot from the AAC output pane. In answer to the questions in order posed:

We're running VIX version 1.11.0.18997 so I'll look to downgrade to 1.10.3.

Our VMs are sat in an "AdminStudio" folder as we have hundreds of VMs. However if they need to sit off the root then that's how they'll be. I'll probably try that step before re-installing VIX.

The vSphere permissions you've described go a tiny bit beyond what we took from the documentation. A "VM Power User" template role was what we used but that lacked the "Backup operation on Virtual Machine" so I'll adjust accordingly.

I've verified RDP to the VM, the designated account is a in the local administrators group on the VM which seemed to be the most effective way to ensure that the account had all the privileges it needed on that machine.

The machine sits in a "dev" OU which excludes all but a few enforced group policies. We do have an "Interactive Logon" policy which is enforced but I've noticed that when the VM starts that's not presented so I assume AutoAdminLogon is bypassing that.

I've watched the VM start through the console view in vSphere and it automatically logs on and the Repackager grey window appears.

I'll report back today once I've run through these steps.

Many thanks,

Iain

[iainjo]

Evan,

Some progress. I made the changes listed below and still the same error.

What I've checked and changed:

• Moved the vSphere AAC VM from a folder to the root
  
• Granted the vSphere AAC VM the "Administrators" role for full permissions
  
• Downgraded VIX to version 1.10.3.16210
  
• Checked and configured group policy; ensured the "interactive logon message" isn't presented, there's no screen saver and that no other policies are in play
  
• Double-checked that RDP to the client
  
• Double-checked that when the VM starts, Windows starts without any user interaction and that the "Repackager" window starts up
  

I've found that the problem is down to the "Virtual Machine Server" credentials. If I use those that have been granted the relevant permissions for the VM, which do allow me to browse and add to the VMs, then the error appears. If I use my own credentials (VMware administrator across everything) then the VM control works and the repackager kicks into life.

I can look to see why the permissions on the account used on the VMs doesn't work, I suspect it needs some additional access at the very top level. For now I can live with that as the guys that will run this process are VM administrators and can use their own credentials when configuring projects.

Notes:

One other issue I had was with the "Windows Shutdown Event Tracker". By default it needs a reason to shutdown the machine so when I was watching the VM console I could see it stuck there whilst AAC was "waiting for the VM to reboot". This was because the VM was already started which it normally won't be but just in case I've disable the event tracker in Windows so that the VM can reapply the base snapshot and reboot unprompted.

Another thought was that this is a domain member server and as we're using a snapshot I've made sure that it is configured to not use machine account password changes.

One other thing is that I found the VM control/repackaging process also works with the machine back in the vSphere "AdminStudio" folder.

Now the key VM part of the process works but the repackager is failing. The extract from the log is attached. Now it may simply be that this isn't a suitable virtualisation candidate, should the process be to test that first?

I've checked the VM; the MSI is being copied down to the correct local folder and the InstallShield project has started to be built in it's own folder.

Looking at the command-line for the repackager there are a couple of trailing backslashes in there that I thought might be a problem but that's probably what repackager expects. Watching the VM console, the MSIEXEC definitely starts (quiet with the basic dialog) but bombs out almost instantly.

I'll try another application or too, something simpler and report back but I thought the information of progress so far might be useful.

Thanks

[iainjo]

I think all is resolved now, there's plenty of information in the previous posts.

The repackager error is because I picked an app that hadn't been repackaged and wasn't ready for virtualising. The AAC is something we've only just started to use to we're slowly getting to grips with how it works.

I ran a simple app through, it didn't need the VM, and that created an App-V package with our server/port config pre-populated in the OSD. All good stuff.

I've still got to get to the bottom of the vSphere "Virtual Machine Server" permissions but at least for now we have a working solution.

Thanks for your help.

[jaybee96]

Hi Iainjo,

Thanks for the info, this has also been an issue for one of my implementations of AAC running with ESX.

It would be great if you could find out which permission is missing on what level.. because our Packagers are "not" VMWare Admins , so I would like to downgrade their current permissions to an acceptable level where AAC is working as expected and VMWare admins are not getting paranoid 😉

Or maybe Flexera can add some extra information about this issue?

Jeroen

[iainjo]

jaybee96 wrote:
Hi Iainjo,

Thanks for the info, this has also been an issue for one of my implementations of AAC running with ESX.

It would be great if you could find out which permission is missing on what level.. because our Packagers are "not" VMWare Admins , so I would like to downgrade their current permissions to an acceptable level where AAC is working as expected and VMWare admins are not getting paranoid 😉

Or maybe Flexera can add some extra information about this issue?

Jeroen

We're in a similar position as we expect to hand this over to people dedicated to packaging and who will have very limited rights over the VMware infrastructure.

I'll certainly report back once I've hopefully found the solution.

[jaybee96]

Thanks!

Success!