This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
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:
But you might see also entries like this:
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
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