mikebarnett's Posts

Ah, I see. Yes, once the Parent VM has been started on the new hardware both CPUs will exist in Windows. Windows won't clean up the old one so it will remain in place preventing the message from ... See more...
Ah, I see. Yes, once the Parent VM has been started on the new hardware both CPUs will exist in Windows. Windows won't clean up the old one so it will remain in place preventing the message from appearing again. -Mike
To correctly handle this situation you should power on the Parent VM once the new hardware is in place to allow the notification to show up there. Reboot the machine and ensure that the new CPU h... See more...
To correctly handle this situation you should power on the Parent VM once the new hardware is in place to allow the notification to show up there. Reboot the machine and ensure that the new CPU hardware is showing correctly in Windows. Once this is complete, power down the Parent VM, take your snapshot and recompose. This will allow the linked-clones to operate normally with the new CPUs without the users having to see the message and reboot the VMs themselves when they login for the first time on the new hardware. -Mike
Hello DS, To use the Blast protocol you must have both port 443 and 8443 open. Port 443 is used to server the View portal for users to download the thick client as well as access the Blast cli... See more...
Hello DS, To use the Blast protocol you must have both port 443 and 8443 open. Port 443 is used to server the View portal for users to download the thick client as well as access the Blast client login. Port 8443 is the port used to tunnel the Blast traffic through the Security Server or Connection Server to the end desktop. These are different services and require different ports. Both connections are secured via SSL. -Mike
There is the possibility for issues arising but I wouldn't classify them as corruption. The database could become out of sync with Composer/vCenter, etc if provisioning operations of some sort we... See more...
There is the possibility for issues arising but I wouldn't classify them as corruption. The database could become out of sync with Composer/vCenter, etc if provisioning operations of some sort were executing at the time of the restarts. Without seeing logs or the DB itself it's hard to speculate exactly what happened. In general View should recover normally from any kind of restart of the servers. -Mike
You cannot have 5.2 and 4.6 Connection Servers in the same production cluster. The upgraded CS will upgrade the AD LDS schema and cause problems. The only supported method for upgrading is to ... See more...
You cannot have 5.2 and 4.6 Connection Servers in the same production cluster. The upgraded CS will upgrade the AD LDS schema and cause problems. The only supported method for upgrading is to install a 4.6 Connection Server on Windows Server 2008 R2, decommission the old CS (ie. uninstall), then upgrade the Windows Server 2008 R2 View 4.6 CS to 5.2. -Mike
If you shut down the Connection Servers the VMs will also not be powered on. If you are bringing the entire environment down just bring down the CS cluster and View Composer first and then no Vie... See more...
If you shut down the Connection Servers the VMs will also not be powered on. If you are bringing the entire environment down just bring down the CS cluster and View Composer first and then no View operations will be triggered during your maintenance. -Mike
If the pool itself is disabled I believe power ops and provisioning ops can still occur. If provisioning on a pool is disabled no automated operations will be kicked off against VMs. This incl... See more...
If the pool itself is disabled I believe power ops and provisioning ops can still occur. If provisioning on a pool is disabled no automated operations will be kicked off against VMs. This includes power ops as well as provisioning tasks. I believe Resets may still be sent but I'm not 100% sure. -Mike
Sounds good. I would recommend backing up everything before starting just to be sure that you have the data in case something does go wrong. Yes, if you are not using tunnelling then you will ... See more...
Sounds good. I would recommend backing up everything before starting just to be sure that you have the data in case something does go wrong. Yes, if you are not using tunnelling then you will not affect currently connected sessions as you run through the migration. -Mike
The first two metrics to look at are CPU and RAM because they are the easy ones. With 4GB of RAM and 2 vCPU per desktop you're looking at 1.2TB of RAM. Since we get about 8 vCPUs/physical core... See more...
The first two metrics to look at are CPU and RAM because they are the easy ones. With 4GB of RAM and 2 vCPU per desktop you're looking at 1.2TB of RAM. Since we get about 8 vCPUs/physical core on average with VDI you can assume you will need ~75 cores to handle this workload. With dual socket 8 core CPUs (16 cores/server) you would need 5 hosts to handle the load with a 6th for failover. With those CPU numbers you would then need ~256GB of memory per host to handle the load plus one server for redundancy. So basically: 2x8 core CPUs 256GB RAM As for storage, if you're looking at standard office/task workers and not power users 100 IOPS will be overkill, unless you have an app that is going to drive that. 30,000 IOPS is going to cost quite a lot. I would recommend taking a look at this guide for general sizing but specifically the section on page 7 about storage sizing: http://www.vmware.com/files/pdf/view/Server-Storage-Sizing-Guide-Windows-7-TN.pdf 20 IOPS per desktop is likely a good starting point. This will put you at 6,000 IOPS instead of 30,000 which will cost a lot less. For added room for bootups/peaking you could go as high as 8,000-10,000. You can take those numbers back to your storage vendor and get some pricing based on those numbers. Hopefully this is helpful. -Mike
OK, so there are a few considerations here. If you are going to migrate everything at once you can certainly install replica Connection Servers in the new site to have the data replicated over... See more...
OK, so there are a few considerations here. If you are going to migrate everything at once you can certainly install replica Connection Servers in the new site to have the data replicated over. Once the new Connection Servers are up you can simply uninstall the old Connection Servers from the original site. You can't run the old Connection Servers and the new ones in production as you will run into issues. You won't corrupt the database as long as the link is stable during the time you are doing the install/uninstall. There is no such thing as a 'primary' Connection Servers. They are a cluster and all operate on the same level so there is no need to do anything special once you uninstall the old servers. For backup, just backup the database of each component. View does an automatica backup each night at midnight by default so you can just grab the latest files. This includes an AD LDS (formerly ADAM) backup as well as a View Composer database backup. The vCenter database and Composer databases can also be backed up using the built-in SQL backup. As for accepting connections, technically View could continue to accept connections but you may run into some connectivity quirks as View isn't designed to operate in this manner. If it is a very short window then you should be OK. Let me know if you have more questions or if anything is unclear. -Mike
Hi Jeremy, When creating a manual pool there is no explicit customization that occurs inside the VM. The VM is simply added to the View UI in that pool. What you should see though is a reco... See more...
Hi Jeremy, When creating a manual pool there is no explicit customization that occurs inside the VM. The VM is simply added to the View UI in that pool. What you should see though is a reconfiguration task kick off as soon as you add the VM. This adds some information to the VMX file of the VM so the Agent can read it and connect to your Connection Server. Two common reasons we don't see this complete successfully are: a) The vCenter Administrator account you've provided in the View Admin UI doesn't have sufficient permissions To fix this simply assign a user that has full admin permissions at the top level of vCenter. b) The vCenter Server is showing as red in the dashboard and you haven't accepted the certificate exception. I can see from your screenshot that you only have a single item showing as red in the top left overview. I'm assuming that's your Connection Server so this may not be the problem. If you could grab the VMX file from the VM you're trying to work with and drop it here I can take a look. You can also look inside the file yourself if you like. You're looking for an attribute named "machine.id". There should be a long string in there with various comma separated values. One last question, how much RAM do you have assigned to the Connection Server VM? -Mike
Hi Jeff, To allow the existing desktops to take advantage of the View Storage Accelerator they will need to be powered off to allow it to be enabled. Once enabled the desktops can be powered b... See more...
Hi Jeff, To allow the existing desktops to take advantage of the View Storage Accelerator they will need to be powered off to allow it to be enabled. Once enabled the desktops can be powered back on. This power off needs to be done with each desktop before a given desktop will be able to use the cache. -Mike
To create a Hardware Version 9 VM you will need to use the vSphere Web Client. HW8 only supported up to 128MB of video RAM. I don't think your VMs will be able to use 512MB of memory withou... See more...
To create a Hardware Version 9 VM you will need to use the vSphere Web Client. HW8 only supported up to 128MB of video RAM. I don't think your VMs will be able to use 512MB of memory without hardware cards though. -Mike
Hi Bojan, Can you confirm you are using Virtual Machine Hardware Version 9? Also, do you have a 3D hardware GPU installed in the server hosting the VM? -Mike
(Replied with the wrong account, re-adding my reply.) This KB is not listed as valid for newer versions of View but it still applies. Check to make sure the HP 2FA agent didn't clobber our ... See more...
(Replied with the wrong account, re-adding my reply.) This KB is not listed as valid for newer versions of View but it still applies. Check to make sure the HP 2FA agent didn't clobber our entry: VMware KB: Confirming that the userinit string is configured properly Our entry needs to be last in the chain. -Mike
No, A wildcard certificate will work just fine. -Mike
Happy to help! Post back if you hit any issues getting this up and running. -Mike
You're correct that the clock starts ticking as soon as you login to the Connection Server but only for the client connection itself. The session on the desktop itself is independent of this cloc... See more...
You're correct that the clock starts ticking as soon as you login to the Connection Server but only for the client connection itself. The session on the desktop itself is independent of this clock and is not affected directly. The setting that you want to use to control this more tightly is the "Automatically logoff after" option in the desktop pool settings. This setting allows you to set various policies based on the type of pool the user is using. For example, if you have a Floating pool used for task access with no requirement for persistence across sessions on the desktop itself you can set this setting to immediately. As soon as the client disconnects the desktop will be reset. Alternatively you can set the "After..." option to a small period of time, like 5-60 minutes. This allows the user to disconnect for a short period of time, such as a lunch or coffee break but still be able to log back in and continue on with their session, but the desktop will be logged off at the end of the day or into the evening once the session timeout is hit (if they leave the client logged in when thy go home). Another common scenario is to have the logoff after disconnect option set to something like 17-18 hours. This allows a user to have a persistent session through the week so they get a consistent experience. It also means that each weekend, when the user isn't logging in within 18 hours the desktop will logoff and be released back into the pool. If you need some amount of persistence but a hard timeout on a Windows session itself this would need to be handled by a 3rd-party utility inside the OS itself. Hopefully this is helpful! -Mike
Yessir! You setup Kiosk mode just as you normally would using the View docs and then apply this GPO to cause the Kiosk login to wait at the windows login prompt for a user to log in. -Mike
The setting you're looking for is the AllowSingleSignon policy. Disabling this will cause the VM to require reauthentication at the desktop and will enable the use case you're looking for. Det... See more...
The setting you're looking for is the AllowSingleSignon policy. Disabling this will cause the VM to require reauthentication at the desktop and will enable the use case you're looking for. Details on this setting can be found here: View Agent Configuration ADM Template Settings You will need to install the View Agent ADM template in AD and apply this policy for it to be active. You can also assign the template to just the single VM if needed. -Mike