This was an interesting one i came back across in the citrix forums. The poster had recently migrated their vDisks from their old PVS 6.1 farm to their new PVS 7.6 farm. What they did start to notice was the odd message as per title appearing again when users were attempting to connect to their published desktop. Been a good while since we’d seen these and as i knew PVS was effectively in charge of AD machine account management thought it was too much of a coincidence.
Sure enough turns out the computer account password updates was set to 1 day. This was at odds with the typical 6.1 farm standard of 7 days.
To change in the PVS console right-click the PVS Server and choose Options tab, adjust Days between password updates from 1 to 7
Once they had reset back the interval to 7 days on each server and restarted the streaming service on all was good to go and no more subsequent messages reported by poster. Interesting one as a potential “gotchya” for some.
Just some i’ve found useful when troubleshooting ThinApp packages i’ve put together.
- Launch from the command prompt your application. Is a good determiner of whether you have an entry point issue or not eg i) Run cmd.exe ii) go to folder for application eg c:\program files (x86)\winzip iii) launch winzip.exe – if the app launches ok, indicates something is wrong with the entry point. Check the WorkingDirectory and CommandLine parameters.
- Move suspected files into the support folder: if the application crashes, its sometimes due to the fact that captured DLL’s are not supported to run in certain OSes.
- Package registration: certain apps needs to be registered to be fully functional. Run thinreg.exe to register the package on your test machine.
- Modify the process name behavior: some apps don’t work when they cannot find its processes listed in taskmgr when running. Worth noting here that ThinApp packages hide the original process names. Add ProcessExternalNameBehavior=original to your package.ini and the processes names will be listed
So looking to “migrate” some un-migrate-able apps (at least without AppDNA in my toolbox) into a 2008 r2 environment took a shortcut approach and with our 2003 farm disabled citrix and effectively revertedthem in 2003 terminal services and intended on publishing the apps (or rather desktop) via .RDP files published from our XenApp 6.5 farm. That way at least could finally retire our XenApp 5 farm.
Did get that old chestnut of a message above and various sources point to various fixes. One below fixed all my troubles.
As per http://support.citrix.com/article/CTX204161
In particular the fairly black and white statement:
“Citrix recommends that customers seeking a hardware accelerated browsing experience use an alternative browser to Internet Explorer”
Seen this recently having a scout on the citrix discussions. Turns out fix was fairly obvious to the naked eye but for folks familiar with web interface I know in the past this wouldn’t occur.
Basically if you do have 2 farms being supported by your StoreFront installation if you do publish an application with an identical name on both farms you will see 2 instances unlike if you published via web interface.
More (though that much) info – http://support.citrix.com/article/CTX203712
One key requirement you may come across from your users in a hosted shared environment if utilizing OneDrive for Business may be commonly asked again and again to make their OneDrive files available from Explorer, to do this first download script from below:
Step 2 is to programmatically include it for all users’, obvious means is via GPO, steps for this enclosed:
Microsoft don’t put a stamp of support over these pieces, in fairness being running it in the lab last couple of months and rock solid so certainly beneficial if you are looking to more heavily utilized OneDrive usage
In order to ascertain root cause of IO control issues always good to get digging into the logs, by default not enabled so will need to carry out the following steps – applicable to esxi 5.x/6.x
To enable SIOC logging from the vSphere client:
- Logon to your vSphere client.
- Click on Host | Configuration tab.
- From the left-hand side column named Software, then Advanced Settings. The Advanced Settings pop-up will appear.
- In the parameters list, go down to the Misc section and select the Misc.SIOControlLogLevel parameter.
- By default, it is set to zero, which means it is disabled. To log everything, set the value to
7 in the field and click OK to close the pop-up box.
- You will now be able to see the logs in