Thursday, October 22, 2015

App-V Support Tip: Publishing Server URL is unreachable after upgrade to 5.1

After upgrading App-V 5.0 Management and Publishing servers to App-V 5.1, you may encounter a problem where publishing no longer function properly and the following issues appear:

- Accessing the Publishing URL in Internet Explorer from directly on the Publishing Server (e.g.http://localhost:82, where 82 is the port assigned to the Publishing Server Service) generates the following error message:

The website cannot display the page

- The event below is seen in Event Viewer\Applications and Servers logs\App-V\Server-Publishing-Private\Debug:
Failed to pre-load publishing metadata. 

Message: Object reference not set to an instance of an object. 
Details:  
Stack Trace: 
   at Microsoft.AppV.Server.Publishing.PublishingMetadataSerializer.PackageSerializer.Load(XElement pkgElement, PublishingMetadata& data) 
   at Microsoft.AppV.Server.Publishing.PublishingMetadataSerializer.RootSerializer.Load(XmlReader reader) 
   at Microsoft.AppV.Server.Publishing.PublishingMetadataSerializer.LoadFromFile(String filePath) 
   at Microsoft.AppV.Server.Publishing.DataManager.ProcessRawMetadata() 
   at Microsoft.AppV.Server.Publishing.DataManager.PreLoadPublishingMetadata() 
   at Microsoft.AppV.Server.Publishing.DataManager..ctor()

To know about the cause and the resolution check the below Microsoft Technet link.


Tuesday, October 20, 2015

Can we sequence application entries installing to both C:\ Drive and E:\ Drive - App-V 5.0

Question : Consider application entries are going to both C:\ Drive and E:\ Drive ..
In this case whether we can go ahead with sequencing this application? as these both locations entries will be reflecting in VFS.

Answer : App-V 5.0 won't support multiple drive entries. Below you can find an example.

start the sequencing steps using App-V sequencer 5.0 SP3.

1. Select create a new virtual package.


2. Select create package.


3. Select standard package.


4. Select custom installation.


5. Enter the virtual package name as test. Click next. In the monitoring phase, Go to c:\programfiles (x86), create a folder named test1 and add a file. eg:1.jpg.

Go to E:\ drive, create a folder named Test2 and place a text file test2.txt.

6. Click "I am finished monitoring"

                                     

7.Select continue to modify the package option and click next.

8. In the package editor select Package Files tab to see the files that were captured during monitoring phase.


Here you can see that only the file that was kept in c:\programfiles (x86)\test1 has been captured in the VFS. 

Conclusion : App-V 5.0 or App-V 5.1 doesn't support file entries installing to multi drive( c:\ and D:\ ) using the sequencer.

Note: However if your application explicitly needs files to be in D:\ or E:\ drive. Simply extract the files from the package and place it in the SCRIPTS section in the package editor. Write a script to copy them to respective D:\ or E:\ drive in the Add/Publish scripts trigger in Deploymentconfig.xml file.Thanks to troubleshooting enthusiastic Vinod Reddy for pointing out this workaround.

Monday, October 19, 2015

APPV_ROOT and APPV_ROOTS - AppV 5.0

Question : When we open CoW local user location we can see that Application has created many folders. Among them we can see two folders with the same name APPV_ROOT & APPV_ROOTS.What is the difference?Any Special reasons why two folders are created?

Answer : When a virtual application requires to make changes to the files or folders during runtime, it does not make changes in package store (%programdata%\App-V).Instead App-V creates Copy on Write (COW) locations and make changes over there during runtime, CoW support both roaming and non-roaming locations.

Roaming CoW Location - %AppData%\Microsoft\AppV\Client\VFS

Local CoW Location - %LocalAppData%\Microsoft\AppV\Client\VFS

In Local CoW location we can see two folders named APPV_ROOT & APPV_ROOTS created during runtime when shortcut makes changes to files/folders.


The S signifies the restricted location when the virtual service requests the change as a different elevated user from the logged on users. The non-S location stores standard user based changes.
In other words from Steve Thomas - Standard users will read and write from the regular directory (with relaxed ACL’s) while elevated processes will read and write to the “S” version.

In a test lab, we have user A named admin who is the local administrator. Lets create four other users USER 1, USER 2, USER 3, USER 4. Among them USER 1 and USER 2 are made as admins and USER 3 and USER 4 are made as standard users. Now Publish the package to the machine globally. When launching the shortcut in admin(local administrator) the runtime files were created in APPV_ROOTS. Launching the shortcut in USER 1 and USER 2, they made changes to APPV_ROOT. The same happens with USER 3 and USER 4 they make changes to APPV_ROOT folder.

Now let us elevate USER 3 and we can see that the changes were written to APPV_ROOTS.

To conclude folders with 'S' (APPV_ROOTS,Common AppDataS, Common ProgramsS,WindowsS etc) are special restricted folders to which only elevated users/Local admin can make changes to.