|
1 2 3 |
for /f %A IN ('type systems.txt') DO ( cscript.exe C:\windows\system32\EVENTQUERY.vbs /S %A /FI "ID eq 3001" /L Application >> list.txt ) |
AppV and Application Compatibility
|
1 2 3 4 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "Q:\\Enterprise Reporting\\ErApp\\erapp32.exe"="WINXPSP3 256COLOR DISABLETHEMES DISABLEDWM HIGHDPIAWARE RUNASADMIN" |
First thing I did was setup a Server 2003 SP1 box and installed the AppV sequencer on it and sequenced the application. I then set it to run on 2008R2 64bit and moved the package over to it. It would crash. Analysing the crash logs would present to me the error… ERAPP32 was crashing its heap. In order to get it to work I had to set it to run in compatibility mode for XPSP3. Once I set this it worked flawlessly. So what I needed to do was push this fix to the rest of our Citrix servers before deploying the AppV application. If you’ve ever read ACT (application compatibilty toolkit) and merging it with AppV it’s kind of a difficult job.
But there is a easier way.
Stored in the registry is the AppCompatFlags key that contains the applications and the shims you can apply to an application. If you put the path to your AppV application it will actually enable it to run in the compatibility mode that you specify. This was my registry entry:
|
1 2 3 4 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "Q:\\Enterprise Reporting\\ErApp\\erapp32.exe"="WINXPSP3 256COLOR DISABLETHEMES DISABLEDWM HIGHDPIAWARE RUNASADMIN" |
And now the application works almost wonderfully (ER is a painful application)
🙂
Read MoreIssue with Folder Redirection (Error 267)
So we were having an issue with Folder Redirection today with a user. We were moving them from a fileshare to a UNC path. The difference is a file share is explicitly shared, the userdirs$ is a share that then has a folder within.
This was the error in fdeploy.log (enabled here).
%%267. After some brief investigation it was found this users had a huge My Docs and it was copied to the new server. The old directory was then renamed (user1.old) and a new directory was created called user1 and reshared as user1$ on the old server. Then this issue occurred. The reason this issue occurred was because the user wasn’t assigned any permissions on the old directory so it was erroring out. I don’t know if %%267 is a permission code or not but that’s what we found. By adding the user to the folder \oldserveruser1$ as full control did it then proceed and migrate his My Docs correctly.
Read More