Visma respects the PendingReboot flag in Windows, but doesn’t indicate that in it’s displayed error messages. Reboot your machine prior to the upgrade.
When tasked with updating Visma Lön running on a Windows Server 2012 R2 machine to version 2017.12 we faced an ambiguous error message during the initial uninstall stage of the upgrade. It translates to: “The installation of Microsoft SQL Server 2008 R2 Express RTM (x64) SP1 (VISMA) UNINSTALL failed. Installation failed.”.
When trying to replicate the error in a lab I’m faced with the same kind of error, but one step prior, translated to: “The installation of Visma Assist SysPreControl failed. Installation failed.”.
This particular version update does not only update the software itself as per usual, but also requires an upgrade to the underlying SQL Server version, this is much approved, as the 2008 R2 version previously used has a few years on it’s legs at this point. This does however result in the update process being a far more inclusive one than we’re used to.
The update will uninstall the SQL Server 2008 R2 VISMA instance and replace it with a 2014 Version, of course, leaving all your data intact, followed by upgrading the databases themselves when started.
The upgrade will require a server reboot, but this is hinted at during the install.
The error faced shows up pretty much right away, as we’re not able to Uninstall the 2008 R2 instance in order to make room for the 2014 install.
The usual suspects of running the install as admin, making sure it’s unblocked, and setting up AV exceptions for the .exe had no positive effect. We even tried running the update as another user as well as in /console. No dice.
Visma stores it’s process logs in %temp%\. This makes the Installationen av Visma Assist SysPreControl misslyckades. error easily solvable;
Open the log file %temp%\VismaAssist Visma Lön YYYY-MM-DD.log and head all the way to the bottom of it.
InitTask: Installed type: Server, Registryvalue ProgVer=300
Configuration has ended.
As seen the log clearly states that a reboot is requred, more specifically due to the PendingFileRenameOperations value.
Simply remove the value, the install should proceed.
The usual heads-up apply to prodding about in the registry, make sure you have a backup prior.
Value to remove: PendingFileRenameOperations
Key: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
If you’re faced with the Installationen av Microsoft SQL Server 2008 R2 Express RTM (x64) SP1 (Visma) UNINSTALL mysslyckades. error, the log file used above wont get populated, however the error is in the same vein.
You could dig through the SQL Server logs located at %programfiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\. The error will show up along the lines of:
2017-08-30 09:22:02 Slp: Exception type: Microsoft.SqlServer.Configuration.RulesEngineExtension.RulesEngineRuleFailureException
2017-08-30 09:22:02 Slp: Message:
2017-08-30 09:22:02 Slp: Data:
2017-08-30 09:22:02 Slp: SQL.Setup.FailureCategory = RuleViolationFailure
2017-08-30 09:22:02 Slp: DisableWatson = true
2017-08-30 09:22:02 Slp: Stack:
2017-08-30 09:22:02 Slp: at Microsoft.SqlServer.Configuration.RulesEngineExtension.RunRulesAction.ExecuteAction(String actionId)
2017-08-30 09:22:02 Slp: at Microsoft.SqlServer.Chainer.Infrastructure.Action.Execute(String actionId, TextWriter errorStream)
2017-08-30 09:22:02 Slp: at Microsoft.SqlServer.Setup.Chainer.Workflow.ActionInvocation.ExecuteActionHelper(TextWriter statusStream, ISequencedAction actionToRun)
2017-08-30 09:22:02 Slp:
2017-08-30 09:22:02 Slp: ----------------------------------------------------------------------
2017-08-30 09:22:02 Slp:
2017-08-30 09:22:02 Slp: Error result: -2067919934
2017-08-30 09:22:02 Slp: Result facility code: 1214
Also kindly stating that a reboot is required.
If you prefer the GUI way you could simply attempt to manually Unstall the VISMA instance of SQL Server 2008 R2 Express using
appwiz.cpl as per usual. This will get you to the Restart Computer fail during pre-checks.
Solution: Reboot Prior to upgrading in case of error.
Visma doesn’t forward the underlying app errors to it’s error messages, resulting in a confusing troubleshooting process and a virtually impossible error to throw at the Google Hive-mind.
Hopefully this will help.