Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
App-V Publishing Fails If You Apply UserConfig Files
Published Feb 19 2020 05:54 AM 4,558 Views
Microsoft

 

Hi there, my Name is Sebastian Gernert and I am Escalation Engineer for App-V, at end of 2019 we get a few reports by customers that Application Publishing is failing when using a User Configuration File applied to these Packages. After some investigation we could now outline the Issue, the root cause and the solution for it.

 

Problem Description

 

You’ll notice that after you apply a UserConfig File in the App-V Management Console that the Publishing fails.

If you look up Verbose logging you find the following entry:

 

5756 [7]14D4.4320::12/10/19-08:28:34.9973489 [Microsoft.Windows.AppMan.AppV] LOGLEVEL=1, MESSAGE=Catalog: Failed to set the last modification time on policy file 'C:\Users\sgern\AppData\Roaming\Microsoft\AppV\Client\Catalog\Packages\{1D45F06B-874D-4A85-86EF-2330B430E47D}\{DB5DE6F6-15E8-4932-A7CF-2DA12EA5B068}\DynamicConfiguration.xml. Error code: 0x0FD0A725-00000057, FUNCTION=AppV::Client::Catalog::DocumentStoreImpl::SavePolicyDocumentToFile, LINENO=1078, UTCReplace_AppSessionGuid=true

 

The Error 0x0FD0A725-00000057 is coming back from Windows and means “Wrong Parameter”

You might notice that some Package with User Config applied might be published correctly, but some are failing. If you publish the Package with Config using PowerShell, all is working as expected.

 

Root Cause

 

As you can imagine, there are no changes on the Server for a while so how could that be?

After investigating and debugging the App-V Client Service we found out that we fail on setting the  timestamp of the UserConfig File, in more detail if the API checks if the timestamp, which will hand over to the API as parameter is valid. And here we found out that the Milliseconds are marked as an invalid parameter. With that knowledge we should look at the Publishing XML and here we see entries like:

 

BrandonWilson_0-1582120087860.png

 

But you might see also entries like this:

 

BrandonWilson_1-1582120087863.png

 

And you also notice that Packages with the 2 digits in the Milliseconds get published but the one with seven will fail.

 

When you use PowerShell, the time will be picked up by the App-V Client correctly with just three digits on the milliseconds, and that’s why it works when using PowerShell.

 

So where is this coming from?

 

The Cause here is coming in a change from SQL Server 2016 and later Versions. SQL Team want to increase the precision, so instead of filling the Milliseconds with zeros – it will be filled with figures 1-9.

More Information here:

 

snip below

 

 

BrandonWilson_2-1582120087892.png

 

As a result, the Publishing XML has a timestamp with 7 digits in the milliseconds area and can't apply this as the used API only allow 3 digits from the Windows side.

 

Resolution

There are two possible options to overcome this:

#1 Change the Compatibility Level of the Database to something lower than 130

For #1, you can change the Compatibility Level following these instructions.

 

#2 Change the Datatype of the column used for the timestamp

For #2 here is a sample Script (note, depending on your DB Naming this script should get reviewed and adjusted) – please make a backup before you run it on your DB.

 

USE  AppVManagement

GO

ALTER TABLE dbo.PackageEntitlements ALTER column UserConfigurationTimestamp datetime2(3)

GO

ALTER TABLE dbo.PackageVersions ALTER column TimeAdded datetime2(3)

GO

ALTER TABLE dbo.PackageVersions ALTER column TimeChanged datetime2(3)

GO

ALTER TABLE dbo.PackageVersions ALTER column TimeEnabled datetime2(3)

GO

ALTER TABLE dbo.PublishingServers ALTER column LastPublishingAttempt datetime2(3)

GO

  

We will also write up a KB for this and it will be linked here as well.

 

Thanks, and have a good Day

 

Sebastian Gernert – Escalation Engineer App-V

 

Version history
Last update:
‎Feb 19 2020 05:54 AM
Updated by: