11-04-2009 02:17 PM
Several times, I've attempted to install Premium for Web 2010 on my company's Microsoft Small Business Server 2008. The install process displays the status message of "Deploying and attaching the SQL Express/Demo Database", then fails with the unhelpful message of "ACT! has encountered an error and needs to close". It presents me with an option to submit an error report, but even that fails with "could not connect to the feedback site".
The installation installs SQL Server Express 2005 (ACT7 instance), but not the demo database. I've tried uinstalling theSQL Server instance and repeating the installation process with the same result. I can't proceed.
In a file named "SecCmdLnOutPut.txt" in "program files(x86)\act\act for web" there's a single line that reads:
Reset Error: System.Data.SqlClient.SqlException: Login failed for user 'sa'.
I've even tried installing an instance of SQL Server manually, but the install process doesn't seem to recognize it. It just reinstalls the instance.
The whole point of getting this product was the web access feature and it won't even install. Anyone have an idea?
11-09-2009 07:55 AM
Welcome to the ACT! Online Community. Are there other applications on this server that use SQL? Was ACT! or ACT! for Web previously installed? Also, I assume this machine is using a 64-bit O/S.
Note: Effective 6/1/13, Sage no longers provides support for the Act! software. This is now provided by Swiftpage.
11-09-2009 09:05 AM
Yes, the OS is 64-bit. SQL Standard 2008 is installed on the server and is used by other applications. This is a brand-new installation of an ACT product on the server. The ACT installation process installs SQL Server Express 2005 just fine (the ACT7 instance is even activated), but fails when attempting to attach the demo database. That brings the whole process to a halt.
Thanks for your interest!
11-09-2009 04:02 PM - last edited on 03-30-2010 07:46 AM by ghollister
I had the same problem on a Windows 7 64bit install of Act 2010 Premium when I already had SQL 2005 installed for another program. When running the ACT setup it would install the ACT7 instance of SQL server but would then give an error message with the following details:
"ACT! Installer has detected that the ACT7 instance is either not running or disabled.\n\nSystem.ComponentModel.Win32Exception: The system cannot find the file specified at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at PrereqCommon.SQLMethods.HardReset(String strSecurityCmdLnApp, String ACTPath) at PrereqCommon.SQLMethods.InstallSQL2005(String SourcePath, String ACTPath, String Param, String strSAPWD, Boolean InstallSP) at PrereqCommon.SQLMethods.PrepareAndInstallSQL2005(String strSrcPath, String strSQLPath, String strACTPath, String strSQLAccount, String strSQLCollation, Boolean IsSPNeeded)"
I went through a bunch of hoops to finally get it working. Not sure what actually fixed it, but here are a few things to try in random order :-P
1. Make sure that the SQL Server (ACT7) and SQL Server Browser services are set to start automatically and that they are running when you try the install.
2. Make sure that Named Pipes and TCP/IP Protocols are enabled for the ACT7 instance using the SQL Server Configuration Manager
3. Try uninstalling the ACT7 instance using the Microsoft SQL Server 2005 option from the Programs and Features menu.
4. Try running the SecurityCmdLnApp.exe program using ACT!2006#10:10:10 or Mercury!2008!ACT for the password (see below)
5. Make sure to run the Setup.exe from the disk using the Run as Administrator option
If it gives you enough problems you can try using the d:/dependencies/SQLInstall.exe program to setup the database or follow this article to configure a full SQL 2005 or SQL 2008 instance for use with ACT.
I finally got it working after using the SQLInstaller, but even then I still got the same error message, but the installer continued after the error. Also I had to:
1. Create an HKLM/Software/ACT/Install/InstallPath value in the registry and set it to "C:\Program Files (x86)\ACT\Act for Windows\" so that the SQLInstaller would think that ACT was already installed.
2. The SecurityCmdLnApp script at the end of the SQLInstaller failed, so I had to manually open a command prompt as an administrator and issue the following command:
C:\Program Files (x86)\ACT\Act for Windows\SecurityCmdLnApp.exe ACT!2006#10:10:10
NOTE: ACT!2006#10:10:10 was the password that the installer had set for the SA account. I also saw a reference to Mercury!2008!ACT being the password so you can try both. After this the database was setup with all the special ACT accounts and the d:\ACTWG\program files\ACT\ActInstallDir\ActDiag.exe program was able to recognize the ACT7 instance as a valid database engine.
Hope that helps. I'm guessing that it is an issue with either file permissions, the resetting SA password, or the SecurityCmdLnApp program. Best of luck!
[Edit: edited format to fit on screen]
11-09-2009 05:36 PM
Thanks for the input! I've already tried steps 1, 2, 3 and 5. But, you've left me with a number of other things to try.
I've also tried manually installing the ACT7 instance of SQL Server Express per Sage's instructions, but the ACT installer doesn't recognize it and attempts to install another instance. Of course, that fails since there's already an active ACT7 instance.
11-09-2009 07:13 PM
yeah... it did that for me too, but after trying to install the instance again it gave the same error message as before and then it just started working and continued with the rest of the install. I think theStill not sure what fixed it, but after playing with it for more than an hour this afternoon it is finally working now.
01-10-2010 08:27 AM
I finally got a resolution to this problem. I had to allow Sage support services remote access to my server and they handled the installation.
Basically, they manually installed SQL Server Express from the dependencies folder, and then deleted the "prereq" subfolder in that same folder before running the setup process. This prevented the setup process from trying to install the SQL Server again (I was never able to get past that point on my own). At some point in the process, they also ran the SecCmdLn utility to set a password, but I don't remember exactly where they did it (before the ACT install, or after the ACT install and before ACT was started for the first time).
Here are two tips for other SBS 2008 users:
1) ACT requires IIS to be operating in 32-bit mode during the installation process. But, despite references to the contrary in the documentation, IIS can be restored to 64-bit mode after installation as long as the application pool in which ACT is run is set to 32-bit. This allows continued use of Sharepoint, remote access and other IIS-based services that require 64-bit mode. Before starting installation, implement the workaround described in this Microsoft Knowledge Base article to prevent RPC errors in 32-bit mode: http://support.microsoft.com/kb/970259/EN-US
2) A compression module used by the Windows Update Server (WSUS) can prevent the Web Site Administration Tool from operating (Chapter 3 of the administrator's guide for web 2010). The test button fails with a very unhelpful error message. Disable the module as outlined here: http://forums.iis.net/t/1149768.aspx
03-29-2010 06:49 PM
Hey Guys, I ran into the same issue you described this weekend with APFW 2010 on SBS 2008. I've since reinstalled the SBS and returned my IIS to the original 64bit setting. Since we're not using the Web feature, I've decided to install ACT Premium (non-web) instead.
Do you know if the SQL workaround is necessary for ACT Premium (non-web) for the SBS 2008?
03-30-2010 07:43 AM
Tech support had to use the SQL workaround when they installed the non-web version on my behalf.
I later upgraded to the web version myself. I didn't ask them to install the web version because I needed to control when IIS went into 32-bit mode, plus I knew that I'd probably get an argument from them about how ACT! wouldn't run when IIS was operating in 64-bit mode. Their support docs seem to have gotten better but, when I started the process, everything seemed based on Server 2003 and didn't take into account the features of Server 2008.
03-30-2010 08:18 AM