bclyde's Posts

I had that problem. Took me ages to find an answer. You need to take the issuing and root CA and place them into the NTAuthCA, RootCA and SubCA stores in AD. This feeds down to the desktops u... See more...
I had that problem. Took me ages to find an answer. You need to take the issuing and root CA and place them into the NTAuthCA, RootCA and SubCA stores in AD. This feeds down to the desktops using GP Client Side Extensions and provides the complete chain for your enrolling certificate. That error is usually caused my TrueSSO pushing down the certificate correctly but your desktop need trusting it as it doesn't have all the chain to validate it. Run these commands on your AD Controller, then waiting for GP to update on its own (or refresh your desktops) CERTUTIL -f -dspublish <cert file name> SubCA CERTUTIL -f -dspublish <cert file name> NTAuthCA CERTUTIL -f -dspublish <cert file name> RootCA
Hey All, i managed to find a solution for this issue. The issue, well - it isn't really an issue at all if the think long enough about it, App Volumes is just doing what it is told to do; ... See more...
Hey All, i managed to find a solution for this issue. The issue, well - it isn't really an issue at all if the think long enough about it, App Volumes is just doing what it is told to do; its not App Vols fault that your capturing heavy apps :-). Whenever you capture apps in an appstack you also capture their security profile as well. if you have a large appstack, like i did, circa 100GB. Then each application contributes to the size of the Appstack firewall profile. When you go to login as a user to a desktop App Volumes first visualises the OS, then imports the security profile from the appstack to the local desktop. This import/export process can stall logon for up to 40-50 seconds. If you are in a position where your internal Linked or Instant Clones have their domain firewalls down by default then i see this as being a cumbersome task. To stop the delay i did the following: 1) update and mount the problematic Appstack on your App Volumes provisioning machine (Use the VMware Console to do this not RDP as connections with drop later) 2) Open an elevated command prompt and run "netsh advfirewall reset" (this blows all the security config away from the firewall and returns it to default) 3) run "netsh advfirewall set allprofiles state off" (this takes all the firewalls down) 4) close the capture and return the Appstack back to the App Volumes Manager. 5) Delete the user existing writable volume (if they had one) and recreate fresh 6) Assign a user to the new Appstack and login (remember to unassign the original appstack before logging in with the new one) I hope it works for you guys. If however you need to have your firewalls on internally then you need to live with this delay as it needs to copy down to the desktop somehow.
Hello, We we are seeing exactly the same issue, pretty much down to the letter too. Except we are using Linked Clones. Did you find an answer to this? Is it a bug in 2.14.0? Barry
Hi, If you create new Appstacks for 2.11, the default policy includes a line:   reverse_replication….****   This line is meant to improve performance for certain applications which enum... See more...
Hi, If you create new Appstacks for 2.11, the default policy includes a line:   reverse_replication….****   This line is meant to improve performance for certain applications which enumerate heavy keys in the registry.   In some cases  it would cause very long login times, if you encounter this for new appstacks, just remove this line from the policy. Give that a go, see if it helps mate. Barry.  
did anyone get any further with this? This is a good thread!
Thank you very much for posting this, showed up first on Google. I am indeed facing the same java.lang exception error. I also have upgraded to View 6.2, vSphere 6.0 UP1 and indeed run a vSAN.... See more...
Thank you very much for posting this, showed up first on Google. I am indeed facing the same java.lang exception error. I also have upgraded to View 6.2, vSphere 6.0 UP1 and indeed run a vSAN. Was any workaround mentioned until 6.2.1 is released, whenever that maybe?!
Are you using app volumes 2.7 by any chance? I believe there are known issues with writtable volumes. Ray_Handels seems to be very good, certainly better than me with App Volumes, maybe he or ... See more...
Are you using app volumes 2.7 by any chance? I believe there are known issues with writtable volumes. Ray_Handels seems to be very good, certainly better than me with App Volumes, maybe he or another user can help mate.
Absolutely. Having that writable volume is 100% required! if you do do not have the writable volume you will NEED to go Online Mode to prevent the constant downloading of the OST files when users... See more...
Absolutely. Having that writable volume is 100% required! if you do do not have the writable volume you will NEED to go Online Mode to prevent the constant downloading of the OST files when users logon to their non persistent VDI. The theory behind this is that the OST writes to the writable volume once and once only and then travels with your user to any floating desktop in the pool. You need to put some thought into the estimated size of the OST outlook will create (usually 2x the mailbox size) and the number of users initially pulling from exchange etc
Its no Problem - Happy to help Ok I think I understand what you mean. Inside the Outlook ADM GPO template there is a policy that you can enable called "Automatically configure profile based on... See more...
Its no Problem - Happy to help Ok I think I understand what you mean. Inside the Outlook ADM GPO template there is a policy that you can enable called "Automatically configure profile based on Active Directory Primary SMTP address" its in User Configuration\ Administrative Templates\ Microsoft Outlook 2010 \ Account Settings \ Exchange Try that?! That gets rid of the configuration wizard for me. I believe it only works if all the Exchange AutoDiscover is set up correctly in DNS etc. Barry
Hi Charan there's a couple of way you can do it. You can either remove Outlook from the base image and deploy it through App Volumes or remove the whole Office Suite from the Base Image and pu... See more...
Hi Charan there's a couple of way you can do it. You can either remove Outlook from the base image and deploy it through App Volumes or remove the whole Office Suite from the Base Image and push it down through App Volumes. Either way I delivered outlook through app volumes then created the writable volume (using the writable volumes template) From here, I configured Group Policy to enable cached mode. It then started to download the OST file to the users appdata folder. The location of the OST file can be changed through the Office / Outlook 2010 ADM template, just make sure you don't push it off to a network drive or anything like that. does it help? Any success since writing your initial post?
Well I'm only reporting what I have seen. initally high IOPS and pull from Exchange in a controlled fashion but then gaining the benefits of having it cached on a writable volume While the des... See more...
Well I'm only reporting what I have seen. initally high IOPS and pull from Exchange in a controlled fashion but then gaining the benefits of having it cached on a writable volume While the desktop remains clean, small and non persistent. what I am trying to archive in VDI is a fast, fluid environment for everyone. This is indeed what I have now with cached mode on a writable volume. I agree you shouldn't put PST/OST's on a network drive. But as you said it's a VMDK that is local to the desktop and therefore operating as normal. (Not sure why you put that when you said it yourself) no where dictates the writable volume needs to be on fast storage it's just recommended, and I agree and understand why. But for OST's it's happy on SATA. Everyone to there own I suppose, but it is supported and if you want a jitter and freezing free outlook and have some free San space this is the way to go.
HI Ray, Too too late i'm afraid! I've rolled it out to 100 test users and it works an absolute treat. Outlook opens ans runs like a dream, the VDI seems sharper and more responsiveness. Gitter... See more...
HI Ray, Too too late i'm afraid! I've rolled it out to 100 test users and it works an absolute treat. Outlook opens ans runs like a dream, the VDI seems sharper and more responsiveness. Gitter and lag in outlook scrolling has gone. And after the initial OST sync my PCOIP has dropped like a stone. i'm in 100% agreement with you it does pull down the profile and generates iops but if you control this to say 10 users in the morning and 10 in the afternoon it's controllable and only happens once. Once the OST is there, that's it. SAN space isn't an issue, cheap SATA drives for the OST is more than sufficient. All test users have a Exchange mailbox of approx 15GB. so a 40GB writable volume was allocated so 4TB of SATA space used. In my opinion a very good trade off for better office performance. all im saying is give it a go before you reply. It's easy to setup and works really well.
Hi Community, My VDI users are suffering terribly with Outlook 2010 using Online Mode. Outlook freezing, pausing, poor searching, calendar updates etc etc. I know its Exchange 2010 back end re... See more...
Hi Community, My VDI users are suffering terribly with Outlook 2010 using Online Mode. Outlook freezing, pausing, poor searching, calendar updates etc etc. I know its Exchange 2010 back end related as the CPU and Memory are sitting under 20% utilisation and disk is 0.01% latency. As my environment is non persistent having Outlook Cached Mode has always been out of the question but since purchasing App Volumes I've had the thought of delivering Outlook through App Volumes with a writable disk to store the OST file from Cached Mode. This way OST files will persist through sessions and be local to the VDI for cached mode. Has anyone got any thoughts and or experience they can bring to the table such as gotchas or extra config? e.g. Will be OST be created on the Writable Drive straight away or will it want to default to the VDI's vmdk file instead? Office 2010 Standard All important Windows and Office 2010 patches installed May 2015 Thanks Barry
Hi Ray, Sorry its taken an age to get back to you. Your answers were extremely helpful and indeed led me on to how I resolved the issue. If you're in provisioning mode installing an app... See more...
Hi Ray, Sorry its taken an age to get back to you. Your answers were extremely helpful and indeed led me on to how I resolved the issue. If you're in provisioning mode installing an application and it puts a shortcut on your desktop or puts the folders in the start menu, App Volumes wont always pick them up in the capturing process. This is because anything referenced by the local user account or indeed HKEY_CURRENT_USER is totally ignored when you complete the App Stack. To get the program sticking to the Start Menu Programs make sure your program executable lies in C:\ProgramData\Microsoft\Windows\Start Menu\Programs if it lies in C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs then it will not capture that and thus not display for other users. The exact can be said for creating a Desktop Shortcut. If the installer puts the shortcut in C:\Users\%username%\Desktop then its not going to work. Copy the shortcut to C:\Users\Public\Desktop and then it was show for other users. Barry
Ah Ok, Thanks for replying. So in a nutshell, anything other than the initial install will simply not be captured. By copying a shortcut to the desktop it goes in  C:\Users\%username%\Desktop ... See more...
Ah Ok, Thanks for replying. So in a nutshell, anything other than the initial install will simply not be captured. By copying a shortcut to the desktop it goes in  C:\Users\%username%\Desktop and thus not be copied. and if by putting in the licence key in on first start-up it goes in AppData you still have a problem. This means that all users will need to put the key in after they launch the application the first time. Madness! Why would VMware release a fantastic application deployment tool and not allow any customisations to the application after the initial install, it just doesn't make sense. it was soooooo easy to do in ThinApp
I'm having problems with App Volumes and I  cant find any online recourses to help, so reaching out to the community. In Thinapp you would set your provisioning desktop into capture mode, inst... See more...
I'm having problems with App Volumes and I  cant find any online recourses to help, so reaching out to the community. In Thinapp you would set your provisioning desktop into capture mode, install your application, open it up, put a product key in, mess about with pop ups saying "don't show again" etc etc then hit build. and all is well. (most of the time) How do you do that in App Volumes? After I install the application in capture mode I open the newly installed application up, put the licence code in, place a shortcut on the desktop then Click OK to complete, reboot the provisioning desktop and click Complete on the App stack then assign it to a different desktop to test on. The application itself has been packaged fine and appears but it doesn't recognise I put in a licence code when I opened it up earlier nor put a shortcut on the desktop. It seems that anything I do outside the initial install (when still in capture mode) doesn't get captured and carried on to the desktops. Any help would be appreciated, thanks in advance. Barry