App Volumes Capture Error 2755

Had another weird App Volumes 2.15 error recently. I have a few Windows 10 LTSC 2019 capture machines (1809) and was getting error 2755 unable to detect the file whenever the installer would try to start a .msi file.

I tried rebuilding, I tried disabling UAC, Windows Firewall, anything I could think of. After a bit of internet searching I found several articles saying to remove KB4487017 (February updates). Unfortunately, there was no relevant KB to delete.

After a few more frustrating attempts, I came across a post recommending the following registry change:

on the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\svdriver\Parameters add the following to the HookInjectionWhitelist

*msiexec.exe ||*

This solved it for my environment, hopefully it will help you as well!


App Volumes Database Password issue

Recently I encountered a strange issue with App Volumes and the ODBC connection. Whenever I would install App Volumes Manager, it would accept my DB entry and credentials. However, when we try to access App Volumes Manager, it would give an error stating Login Failed. The SQL logs also stated “password mismatch”.

I tried to re-enter the known good password but the issue would persist. I searched high and low for an answer and finally called in the help of a colleague. After spending some time with me, he remembered a similar issue he had during a recent installation.

The issue was the password had a symbol in it. In my case, a percent sign (%). While this is a perfectly fine character for a SQL Server password, App Volumes has a problem with it. This is due to the use of Ruby on Rails in App Volumes. Ruby uses the % character for string interpolation. Once I used a password with out the %, everything worked as expected.

I suspect any special character that Ruby uses for string manipulation would have a similar issue. This was a frustrating issue and seems to be undocumented by VMware. It would be nice if the installer would test for characters not allowed, but for now, be aware of the issue.


VM Deployment with PowerCLI Part Two

In my last post I presented you with the main deployment script I have been using. What it did not include are all the little tweaks and prerequisites that allow it to work.

The first thing we need before running the script is a Template. As previously mentioned, I built a vm from the corporate standard ISO. I then applied updates and added some post deployment scripts to do things we couldn’t do with NEW-VM or the customization specification.

Here are the files I used. Some consolidation could be made and your mileage may vary:

This simple .bat file is called by the customization specification. It is calling two other powershell scripts, installing sccm client and restarting the vm to finish up the installs.

The first file called is:

This file sets the SNMP properties, updated DNS servers, disables IPv6, adds domain suffixes and renames the local guest account

The next file:

This file adds our AD admin group to the local administrators group on the vm. It also renames the local Administrator account. You may notice the calling of the legal.reg file. This was needed because we have a legal message displayed after login, and it was causing us to have to interact with each vm to get it through the customization process. We disabled the legal notice in the template, and reinstate it using the registry key.

Here it is, masked for business sensitive information, of course:

Now that we have talked about all the scripts and their functions, lets move on to the last, yet very important piece: The customization specification.

I created one specifically for this build process as I needed to customize it a bit more than we were doing normally. I needed credentials with domain joining ability, the proper domain specified in the CS and adding pre.bat to the run once field.

As you can see, not terribly complicated. Definitely room for improvement. And, with the addition of some actual automation tools, could become much more powerful. This was simply my way to reduce busy work within the confines of our environment. Please feel free to use this, pick it apart or send me beer if you really liked it :)


VM Deployment With PowerCLI part one

Tedious, repetitive processes are the number one factor in deciding whether to write a new script. In my current position, we are asked to deploy new VMs on a pretty regular basis and in some cases it may be upwards of 20 in one batch! The standard way we accomplish this is through the following steps:

1. Create a new VM using the vSphere client, setting the general parameters
2. Attach the vendor created ISO that will do all the customization to the selected OS. (this step takes 30-60 minutes)
3. Set SNMP properties
4. Set IP and DNS settings
5. Disable IPV6
6. Add DNS search suffixes
7. Rename local Admin and Guest accounts
8. Install SCCM 2007 Client
9. Add our AD security group to the Local Administrators group
10. Install Cisco AMP

As you can see, there are a lot of steps in the original build process. For one off VMs, this might be acceptable. However, when you need 24 VMs for a big project, it could easily take several work days of your time. This is when my distaste for repetitive, manual processes comes into play.

The first thing that comes to mind, is how much of this can be streamlined through PowerCLI. As it turns out, most of it! Now, having no official automation tools or even support from within to accomplish this task, I had to improvise. This means there are a few factors other than PowerCLI in play. I have a .CSV file containing all the fields necessary to complete the build. Batch files and small Powershell scripts to do some customization. Custom VM Templates and Customization Specifications. As you can see, quite a few tools being used to achieve our modest goals.
The .csv file contains the following fields:

Name – Name of the VM
Template – Name of the Template we are using
Cluster – Which Cluster are we putting this VM in
Datastore – What Datastore should we use
Customization – This is the Customization Specification
vCPU – Number of vCPUs
Memory – Amount of memory
Network – Network the VM should be on
Diskformat – Thick or Thin
Location – Which folder the VM should be in
ipaddress – The IP address
mask – Subnet mask
gateway – Default Gateway
dns1 – DNS server
dns2 – DNS server
disk1 – Disk one size
disk2 – Disk two size (if no disk two, 0 or leave blank)

The .CSV file has the above names as the first set of values. So the next step in the new process is: create/edit the .CSV, in my case, it is named NEWVMS.CVS

Now we are ready to start the actual script.

First we need to get the data from the .CSV

Something I decided to add was a time/date stamp and who built the VM, so we need to get the username of the person running the script (another thing you may consider adding is a project name or sponsor.

Now we get to the fun stuff, importing the data and assigning it to variables

One more step before we build the VM, Set the IP, subnet mask, default gateway and DNS servers in the Customization Specification. If we don’t, we cannot have the VM join the domain using the guest customization routines.

Now we can finally call the New-VM cmdlet and build the VM

Now we will set the VM name, Amount of Memory, Number of CPUs and the Network the Primary NIC will be on

the last few steps are add the second disk (if it exists), set vm built date and builder in the notes field and start the VM!

At this point the VM build process is complete. But wait! What about the other steps? I will cover those in detail in my next post. for now, here is the complete script:


VMware tools and PowerCLI part 1

Recently I noticed a few servers did not have VMware tools installed. Needing to see how big of a problem this was, I turned to a few old standbys: RVtools and PowerCLI.

Of course, RVtools was able to provide the info relatively quickly, it was cluttered with extraneous information. I could have chosen to pair down the data by sorting and removing lines, but that seemed like work.

PowerCLI to the rescue!

Having not done this particular task in PowerCLI, the first thing to do was determine how to get the info. A couple of searches later and the VMware tools status was found in the extension data of get-vm: ExtensionData.Guest.ToolsVersionStatus

Great, now to use that data:

So, a relatively simple one liner to find the VMs with no tools installed. Not being one to stop there and putting google to use once again, I found an article that suggested using New_VIProperty to make it easier to understand and use in the future.

Here is the same thing except we are using New-VIProperty to add some clarity and ease to the process:

The New-VIProperty cmdlet is very useful! While certainly not needed in the above examples, it gives us building blocks for more complex scripts. Stay tuned for more on VMware tools and PowerCLI.


My vMetrics

Total Metrics:
34 GHz Total CPU
96 GB Total RAM
4,135 GB Total Disk
1 Host(s)
2 RPs
25 VMs
128 vMotions
Power States:
(18) (7) (0)
Networking:
5 Physical NICs
18 Virtual PGs
Cluster:
Lab
DRS:
HA:
Current Deviation: 0
Target Deviation: 0
DRS Balance:
Hardware:
Dell Inc. PowerEdge R720

previous refresh
1984 days, 20 hrs and 25 min.

Recent Comments