Recently ran into a issue where within Hyper-V Manager under the vswitch settings for a specific hyper-v node the NIC had changed to “INTERNAL” and it would not let me change it back to EXTERNAL. I received the following error:
- ” Cannot bind to … because it is already bound to another virtual network”
This was found when I was troubleshooting why the hyper-v node in question was unable to connect to the CSV. The following changes resolved the issue:
- Remove this registry setting “config” from HKLM\SYSTEM\CurrentControlSet\Control\Network\Config and reboot the server.
After that you will need to reconfigure the vSwitch information, also check that the ip address is set correctly on the Hyper-v node.
If this task is being completed on a hyper-v node that does not have a GUI Microsoft support suggested removing the Network cards and reboot. The command line way to accomplish this is below:
On the hyper-v node in question run the following commands::
- netcfg -u vms_pp (ENTER)
- netcfg -c p –i vms_pp (ENTER)
This removes the virtual network switch and then reinstalls it. After the reboot you will need to reconfigure the network card/vswitch.
Running the command above accomplishes the same thing as editing the registry so you should not need to do both. At this point I am unsure what caused the issue only that this seemed to fix it.
I have ran into this a few times now and each time I have seen it I was installing XenApp 6.5 on a syspreped version of a Server 2008 R2 baseline. So here is how it has played out:
- I build a patched Server 2008 R2 baselined image.
- I run sysprep on the image and set it to gereralize the image and shutdown vs reboot.
- I create a new VM based on this sysprep disk
- I boot the new VM the Sysprep finishes
- I change the password, rename and configure the new image (reboot)
At this point I install Xenapp 6.5:
- The installation process goes well and then during the Configuring Server part of the installation I am presented with the following message:
Now as I mentioned earlier in this post I had seen this error previously, but for some reason I hadn’t posted the fix here. Luckily this particular issue stuck with me because the fix was something that I would never have tried had I not just had a discussion about sysprep. So here’s my fix:
- Hit Finish to end the install (we restart this later)
- From a powershell window run: msdtc -uninstall
- Then run: msdtc -install
- Now reboot the server
After the system comes up log in, rerun the Xenapp Server Configuration and the installation will complete without issue:
Ran into this a few time when I moved a VMs folder (including its vhdx file) from one storage location to another. To resolve this I ran the following command from the command prompt***NOT POWERSHELL:
icacls “Vhdx file or VM folder” /grant “nt virtual machine\virtual machines”:F
Once this command is completed and the nt virtual machine\virtual machine “special identity” is granted full permissions the VMs will start again.
In my opinion one of the cool things about application/desktop virtualization is that users can pull their application/desktop session when they move from one location to another. However you may run into situation, as I did where customers have concerns about this capability. I would guess that this is uncommon and as such it is not common knowledge. I could be wrong about that but if I am at least I will have this noted for future reference.
To limit users to one session of an application do the following:
- Open Appcenter
- Open applications folder
- Right click the application
- Select application properties
- Under advanced
- Select limits
- Check box next to “allow only one instance of application for each user”
Short and sweet. I am working on getting back in the habit of posting weekly so hopefully I will have more to come. I will be working on AppDNA in the coming weeks application migrations from a XenApp 4.5 to 6.5 environment, I will post any interesting findings.
Limited audience here, but if you need to provide non-domain admins access to your Xenapp farm through AppCenter on a remote server need to add those users to the “distributed COM user” local group on the server they are connecting to.
To do this login to the computer they will be managing the Xenapp farm from.Right-click on my computer then under local user and groups, open the groups folder and make them members of the “distributed COM users” local group. This is useful if you have given “read-only” permissions to the farm to some low level (I mean this in the nicest way) administrators and you want them to do all their management from a remote (base admin) computer.
Thanks for viewing.