I hit an issue recently that was a little tricky in regards to Access Services and SharePoint 2013. (Not Access Services 2010) The issue arose when saving an Access app that was created in a development farm and trying to publish it to production. Here are the steps to create an Access app package for an on-premises Access app. What was unique about this situation that moving apps in any other direction worked. You were able to go Prod->Prod, Prod->Dev, Dev->Dev but Dev->Prod failed. You were also able to create new Access apps in both environments.
When deploying the app to a site in the production environment these were the errors that were received…
————–
DacManagerPeer.Install: Exception thrown installing DAC. Exception {Microsoft.SqlServer.Dac.DacServicesException: Could not deploy package. —> Microsoft.Data.Tools.Schema.Sql.Deployment.DeploymentFailedException: Internal Error. The internal target platform type Sql110DatabaseSchemaProvider does not support schema file version ‘2.5’. at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeployment.CreateExtensionManagerFromModel(SqlPackage package)
————–
DacManager.ExecuteDacOperation: DAC operation failed with exception {Microsoft.SqlServer.Dac.DacServicesException: Could not deploy package. —> Microsoft.Data.Tools.Schema.Sql.Deployment.DeploymentFailedException: Internal Error. The internal target platform type Sql110DatabaseSchemaProvider does not support schema file version ‘2.5’. at Microsoft.Data.Tools.Schema.Sql.Deployment.SqlDeployment.CreateExtensionManagerFromModel(SqlPackage package)
————–
I had never heard of DAC as it relates to SharePoint (it’s not Dedicated Administrator Connection) before so I had to do some digging. From the sound of the error it sounded like software was mismatched between environments. I first double-checked all of the install tasks to ensure they were completed – Here is a great white paper on setting up Access Services. While going through this I saw that one of the prerequisites referenced DAC, the Data-Tier Application Framework.
So I went and looked at both environments and sure enough there were multiple versions of the Data-Tier Application Framework across all servers (APP & SQL) in both environments. There were versions 10 up to 12 with no standardization. I then went ahead and installed the latest version of the DACFramework.msi file that I could find in the download center which was from June 22nd 2015 and version 13+. I received the same error after this install so I started to dig deeper by going into the Access app package. I first changed the extension of the app package to .zip.
And I found these files:
Great start, time to compare between apps build in Prod vs Dev! At first glance nothing stood out between the manifest and .xml files, but then I started looking into the .dacpac file as I had never heard of this before. Here is what I found:
- A data-tier application (DAC) is a logical database management entity that defines all of the SQL Server objects – like tables, views, and instance objects, including logins – associated with a user’s database. A DAC is a self-contained unit of SQL Server database deployment that enables data-tier developers and database administrators to package SQL Server objects into a portable artifact called a DAC package, also known as a DACPAC.
It was now making more sense. Access Services in 2013 uses an entire SQL DB per app you create. So SharePoint is utilizing the logic behind the DAC framework to package and move databases between environments. (This took software on the SQL server out of the picture). But I must go deeper so lets open up this file…. was able to use the same logic as before and convert the extension to .zip to open it up.
Yay! More files to open and compare. I first looked at Origin.xml and nearly found what I was looking for.
Dev
Prod
Dev has a newer DAC version than Prod. Ok is there anything else? What is this schema error? Opening up the model.xml file I found the answer.
Inside of the model.xml file existed the corresponding Schema for the DB provider that was throwing the error. And sure enough apps created in Prod had Schema Version 2.4. This made sense but I had installed the latest DAC version on both environments? What I found out is that installing the newest DAC framework version 13.0.2993.2 does not upgrade the previous version. I then remove everything I can find for older DAC versions and give it a shot.
Another error? Come on! At least I got a correlation ID.
————–
DacManager.ExecuteDacOperation: DAC operation failed with exception {Microsoft.Office.Access.Services.Design.TemplateException: Sorry, an app package could not be created.
————–
Well that didn’t appear too helpful. The next shot I took was a guess that the version I installed was too new. So I installed the Data-Tier Application Framework August 2013 version 11.1.2902.0 and completely uninstalled version 13.0.2993.2.
SUCCESS! I was then able to successfully add an app that was created in the Dev environment to Prod. Mission completed, let’s load this app and move on…..(queue up loading music)……Error…..dang……
————–
We weren’t able to load the app’s home page. Please let your administrator know about this.
————–
Not helpful, onto ULS logs and actually some helpful info.
————–
The application’s system schema version is newer than what the current version of Access Services understands. AppVersion: 15-0-61-0. ServerVersion 15-0-59-0.
An error occurred reading application properties while opening a command scope. Microsoft.Office.Access.Services.VersioningException: Sorry, the server doesn’t recognize the version of the app you are trying to open.
————–
Alright so more discrepancies between farms. What I found on dev was a hotfix applied KB2956180. I knew this had been there as this was the first place I looked when we had server mismatches at the beginning. I didn’t believe that this was vital as the overall version of Access Services was identical between farms and the KB was a lower build number. Reviewing the KB though had a lot of direct ties into Access Services. This was also a large hotfix (154MB) and required PSConfig to be ran.
I went ahead an installed this hotfix on all SP servers and ran PSconfig on all servers. I then opened the app that had threw an error earlier and the sky’s opened up with a wonderful ray of light and I saw my Access app.
I certainly hope this post will save someone some time as it was quite an adventure. The final breakdown and advice of this post:
- Ensure the same version of DACFramework.msi is installed across your farms
- Ensure you only have 1 version across your farms
- Do not use version 13.0.2993.2 of DACFramework.msi
- Ensure hotfixes (even if lower build numbers) are matched between farms
Happy SharePoint troubleshooting!