10-24-2016 08:48 AM
I second that: thank you, Gary.
I know we can sound kind of whiny out here after many hours of trying to get Act fit into more sophisticated networks that leave the default installation process seeming to be less than well-thought-out, but in the end, our goals are 1) to prompt more thorough testing in relation to common infrastructures and 2) to inspire at least a modicum of additional setup documentation to address some of these issues. In both my recent weekend misadventures with Act, the resolutions were, as is so often the case, very simple; finding them was the issue, since they were completely off the radar of the documentation.
So I am glad we have this forum, not only to gain information and share experience, but as something of a bridge towards dev. Maybe we can all spare the next poor soul hours of wandering in the desert on the way to a successful Act integration in the larger context of an advanced information systems infrastructure!
10-25-2016 12:09 PM
Indeed, this is outside of the scope of what's appropriate for the KB. Since this is not an Act! error, but an error that occurs within a third-party backup system when it attempts to access files related to a database/a Microsoft SQL Server instance without appropriate permissions. While the Microsoft SQL Server instance in this specific scenario happens to be the ACT7 instance, this is not an issue that is solely related to Act!. It can happen with any Microsoft SQL Server instance. We are not able to advise on configuration of Microsoft SQL Server or system permissions outside of that which Act! requires in order to operate.
What we can advise on, are the recommended methods for creating a backup of an Act! database as described here: http://kb.act.com/app/answers/detail/a_id/19211
The Act! Scheduler can be used to create automated backups. Once created, a third-party backup system can create backups of the Act! backup files, which are not attached to SQL Server.
10-25-2016 11:31 PM - last edited on 10-28-2016 01:45 AM by Gary W
Post removed due to inappropriate behaviour
We will not condone abusive language directed towards staff or users of the Community.
- Gary W
10-26-2016 12:15 AM
I have to agree with AnybodyM here. Although SQL isn't an Act product, it is an integral part and if you are bundling it into the installation you have to take some responsibility (in this case, possibly a lack of thorough testing). I think at the very least this deserves a KB article to acknowledge the issue - if only to pass the blame onto Microsoft. Do it as an act (no pun intended) of good faith to your vast user base.
As mentioned, this issue is easily reproducible.
Who's the culprit here? Users will blame act.
It should take no more than 1-2 hours to setup the test if you need further convincing.
10-26-2016 01:00 AM
Thank you, AnybodyM & mikeyorke! I entirely agree with your assessment, based on my all-too recent experience, from which I am still reeling:
So, try to tell me how, from my perspective as an information systems professional, the backup failure is not only Act-related, but Act-induced. Perhaps there is another vendor out there that might provide, without any helpful documentation, default settings that break one's VSS-based backups, but I have no proof of that because Act is the only one I have seen. I still have very little clue as to why this is an issue, since I am not a SQL expert nor a Windows security expert. But, then, I should not have to be, or become, a SQL expert just to integrate Act as one small part of an organization having many more pre-existing applications. In fact, SwiftPage is the development, marketing, and sales organization for Act, which runs on SQL. In my experience with software vendors over the last 20 years, it has always been incumbent on vendors to ensure that 1) they have experts on staff for not only the programming languages, but also for the database platforms for which they choose to develop and 2) they create common environments for testing beside the development team's computers in the company's own network.
Unfortunately, this is not the first time Act has come into focus for me this way. I thought I had seen the end of the old, sloppy ways of approaching things the last time I dealt with Act in a corporate environment perhaps seven years ago. Although Act marketing and sales continues to target businesses with well-managed systems, my experience and the discussion here both do much to confirm the conclusion that SwiftPage development is simply not providing an implementation that is ready for such environments targeted by their sales staff. It goes like this: the Act sales staff markets the product, with no mention of any complications like this, to end users, who then dump a download link and license in my lap (not an unusual practice, by the way) under the entirely misguided assumption that the Act developers must have planned well and thought of everything, and then wonder why I spend my weekends working on something that the Act salesman said was easy. For me, this made two back-to-back Act-specific working weekends; see my other thread here:
In the end, the cost of Act for my client is not just the $25-or-so per month cost of renting the software that their SwiftPage rep told them about, but now also the $2500+ cost of me getting it working in a way that will not break other elements of their corporate environment. And there is anything unique about their corporate environment; it is just something more than a two-bit peer-to-peer environment for which it now seems to me that Act is intended. And this is too bad, since all the technology is there to scale it to larger and more well-managed environments; the only thing keeping it from being scalable is attitude and documentation, both on the part of SwiftPage. With proper documentation, my time might have been four hours instead of now upwards of 30. As an aside, I tried bringing up a number of complex technical questions with Act support before I even installed it, but I could not get the Act technicians to even understand the questions, much less answer them, leaving me at the mercy of my own resourcefulness and some respondents here, for which I am grateful, supplemented with massive doses of inference, trial-and-error, research, and just plain time.
Naturally enough, the blame for all of this will never land on the SwiftPage salesperson for failing to ask about the corporate environment, a key question that most definitely needs an answer for a successful implementation, or so much as mention any of these issues. Nor will it fall where it truly belongs, on SwiftPage development (or, more correctly, management), for failing to resolve, or at the very least, document, these issues. No, it will, as is usually the case, land on me, the hapless information systems consultant, under the end users' assumption that somehow I do not know what I am doing and that if they just had five extra minutes last week, they could have saved us all these headaches by just installing it themselves. After all, the SwiftPage salesman said nothing about any of these things, so it could not possibly be a problem with the product. (And, for the record, had the users done the setup themselves, nothing in the documentation would have prevented them from doing the most logical thing to them: hosting the SQL database on the manager's laptop, thus making it inaccessible to everyone else every time she took it with her on a sales call.)
And I even went to extraordinary lengths to point out here that my post was not intended as a complaint but in the hopes that it would prompt more thorough testing in common environments along with more complete documentation. A "this is not our problem" response to that does nothing to enhance SwiftPage's image here! The end users' experience, in the end, may not prevent them from recommending Act to others, since most of the pain is mine; however, my experience here will most certainly be something I bring up when any of my clients ask about implementing it in the future: "Don't forget the 30 hours of me fixing undocumented/untested things that will probably pop up during setup". That ought to be something SwiftPage management would want to consider, especially considering the fact that, with all of the work being done for you here, it would require just a little more targeted research and testing to provide the basis for some more substantial documentation on the subject.
Welcome to real world, Neo (and @Elise).
10-26-2016 01:30 AM
I must admit I was very concerned to read the view that as it was not a ACT defect it should not be included in the knowledge base. If I worked on this ethos I would VERY QUICKLY go out of business.
Here are the facts -
A client has a working system on their server and backups are being made each night.
ACT is installed and as a result the backup system fails.
A fault is in the SQL program installed as part of the ACT installation is the problem.
YES THIS IS A REASON FOR SWIFTPAGE TO TAKE RESPONSIBILITY AND PUBLISH THE FIX IN THE KNOWLEDGE BASE OR LINKS TO MS SQL KNOWLEDGE BASE ON THE SUBJECT.
For Swiftpage to think otherwise sends a shudder down me about what they perceive customer service is all about. They need to rethink this one if they want to be seen as putting the client above - not my problem guv - ethos on what their responsibilities are to their customers.
10-26-2016 01:40 AM - edited 10-26-2016 01:57 AM
By the way, just one more tidbit on my original issue (just in case SwiftPage every actually decides to test/document further). I went one step further in my testing and changed the logon account for the Act SQL instance, not only from Local System to Local Service, but then to a domain admin account I use explicitly for running services (not the default/builtin-in domain admin account). This worked also, even while leaving the VSS service running under Local System. I also posted the question to an MSDN forum so that I can better understand the interplay between the SQL Server and SQL Server VSS service logon accounts. I will try to remember to post back here if I get an explanation.
10-26-2016 03:54 AM
10-26-2016 04:16 AM
Thank you Gary for your measured and balanced response to the problem and insight into how it is being looked at.
Somewhat more reassuring after the last response from Elise.
We look forward an update once testing etc has been completed.
11-01-2017 02:02 PM
Has there been any progress on this during the last year? I am running v20 and it has this problem.