08-17-2016 10:31 AM
I did think that taking the manual installation of SQL where you determine the SA password might work. Glad it did.
08-27-2016 02:47 AM
I am new to this forum, so please excuse any departure from protocol. I am having exactly the same problems you encountered with ACT and the ACT7 service causing Server Backup to fail when the ACT7 service is running., I am going to try the same thing you did with a manual install of Microsoft SQL 2014 Express. Which version did you install? The install procedure for MS SQL 2014 Express shows the download for the install at: https://www.microsoft.com/en-us/download/details.aspx?id=42299 but there are several options there. My server is running Windows Server 2008 R2 64-bit. Thank you.
08-27-2016 04:29 AM
Problem appears to be fixed. The following procedure worked for me without having to re-install SQL 2014 Express.
Services and Applications
SQL Server Configuration Manager
SQL Server Services
Change Log On from Built-in account: Local System to Built-in account: Local Service
I was able to do a complete automatic backup of the server without shutting down the ACT7 service.
08-30-2016 05:21 AM - edited 08-30-2016 06:06 AM
I suspect this kind of documentation might be outside our scope of support. The community is the best place for this kind of information.
I will pass it on to our helpdesk for learning purposes.
10-20-2016 05:04 AM
I can sympathise with the original poster. I had an Act instance running on a Server 2012 VM (which was sharing the Act database to other Act users). This server was backed up by Veeam Backup and Replication v9 along with all my other VM's.
This server would consistently fail when "application-aware processing" was enabled in the backup job (this essentially invoked VSS to snapshot the database before backing up).
Along with Veeam support we troubleshooted this for a few days. I found lots of posts with similar issues but related to SharePoint. The common factor appeared to be the bundled version of SQL Express had a known typo, which could be seen in the Windows Event Viewer if you were eagle-eyed.
Error: NetLocalGroupGetMemebers(Administrators), 0x80070560, The specified local group does not exist.
Notice the word "Members" in the above error is misppelt.
Anyway, we eventually gave up fixing this issue and just turned off application-aware processing for the job, which skips the VSS snapshot of SQL and takes a dirty backup of the database.
I have recently started using Veeam Endpoint, which also starts failing as soon as Act gets installed (I tested this by building a clean Win 7 virtual machine, backed it up with Veeam Endpoint - completed successfully - installed Act, run backup again - failed).
Having tried lots of things suggested on Google it is ironic I find the fix on an Act forum of all places. Like I say, I don't believe this is an Act issue, but a SQL Express issue.
Kudos to andyman49 for the solution.
10-23-2016 07:18 PM - edited 08-07-2017 08:19 PM
Gary: I think you might want to reconsider whether this is not worth passing on to support for inclusion in a KB. Here I sit, after last weekend's ~15 hour ordeal trying to get Act for web to connect--then finally figured out I had to stick to using the default/built-in domain or local admin account, not just any domain or local admin account for the initial IIS connection in Act → Tools → Website Administration → User Account. On top of that, I had a very difficult time figuring out how to configure Act while respecting company policy that disallows non-hidden shares (i.e. the default Act share). That post is here: http://community.act.com/t5/Act-Premium/Customize-share-name/td-p/328687
This weekend's ordeal, although half as long, was not particularly any less painful. I spent about six hours of my weekend trying to figure out why my Act installation had immediately broken my long-reliable VSS-based backups. The failure itself put our entire organization at risk and, while I fully understand that this is, technically speaking, a SQL issue, it is in my opinion, entirely inexcusable for the Act developers to have failed to test their default SQL installation thoroughly enough in real-world situations to miss this point. Here is that post: http://community.act.com/t5/Act-Premium/Granting-backup-user-access-to-Act-database/m-p/328852#M4332...
The solution, in the end, is what I have found here in this thread, but only once it became apparent that the core verbiage to search related to teh SQL errors, not to the VSS service itself: I have to change the SQL Server (ACT7) instance so that it runs under the Local Service account, not the Local System account. Once I did that, my backups began working. There really needs to be a "SQL setup considerations for VSS-based backups" section in the installation documentation, or, better yet, an implementation that correctly configures the SQL instance to run under Local Service instead of Local System.
And, please bear with me here: this is intended to be constructive, but I will admit that I will sound whiny: it just seems to me that, in their haste to push products out that are easy to install and manage, the Act developers have either failed to test properly or have ignored known facts in their documentation.
Consider the fact that, as an outsourced IT consultant, just solving these two problems alone cost my client somewhere around $2,000 in my time over the last two weekends. Granted, the folks that pay the bills are more likely to associate that cost with me than with Act, so the Act sales staff are well-shielded from any association of this as being part of the true cost of Act implementation, while I am more likely to get a few, "What did you do wrong?" questions before it is all over.
At any rate, I hate having to tell my clients that this is just the cost of buying applications that, while they fulfill or exceed expectations for the users (and, to be fair, I do love Act for what it does for the end user!), they simply fall short of fitting into larger corporate environments. It all makes Act look as though it is designed for a two-bit do-it-yourself peer-to-peer network where the backup plan is a user manually running a database backup from within the Act UI or scheduling it via the Act scheduler. In networks that are actually managed (rather than just sort of happening on their own), though, which describes every one I manage, user-level system management not only distracts users from their jobs as sales or production staff but regularly causes major headaches when it leads users, who care only whether the application works on their desktops, not that installation destroyed my ability to backup an entire mission-critical server, to point the finger at the hapless IT manager or consultant (that would be me) under the entirely ignorant and misguided assumption that the Act developers must have thought of everything and that either my system-level concerns are entirely trivial or that I must have made some egregious error that led to this situation.
And as a bonus: my experience in trying to get tech support to even understand a complex question like this has resulted in zero useful contacts since I began Act implementation a couple of months ago. I have been on my own and at the good graces of you folks here in this community, and I hope you can do something to impress upon Act support that it is important that 1) the developers test these things in more real-world scenarios involving managed systems and 2) the installation documentation process should include some of these gotchas as at least possible areas that might need attention.
10-24-2016 12:31 AM
As before I would also like this in the knowledge base. Anything that helps ACT users resolve problems is helpful and although not ACT fault in this case it is the ACT installation of SQL that causes the problem.