10-07-2008 04:12 PM
The Overall Question:
How the heck can I get ACT 2009 Premium for Web working on a Windows Server 2003 Domain Controller running Sharepoint 3.0? I know that a perfect world dictates I run this on a member server without Sharepoint, but I don't have that luxury right now.
Problem 1: Sharepoint's giving me fits
Problem 2: I also can't make a working ASP.NET impersonation account.
What I've Done - Cliff's Notes Version:
Problem 1: ACT Website Administration says I need further configuration since Sharepoint's installed. Changes to the web.config file have proved fruitless. Plus, ACT's knowledgebase has instructions written for Sharepoint 2.0, which uses a completely different admin portal than 3.0.
Problem 2: I created an ASP.NET impersonation account on my domain following the admin guide. ACT Website Administration claims I don't have permission to use this account when I try to Test it. Remember that this installation is on a Domain Controller, so I can't add the ASP.NET account to a local admins group...instead it's on the domain admins group.
What I've Done - The Long Version:
Problem 1: I attempted to follow instructions on ACT KB article 16514, but it's written for Sharepoint 2.0. And if I'm reading this (http://support.microsoft.com/kb/828810/en-us) right, then the ACT Virtual Directory is already configured properly (was done so by ACT when it was installed, is set as an application, and has its own web.config file). I also attempted to make a separate web site on a different port with a separate virtual directory. Again, I was unlucky, receiving the same web.config errors as before (namely, "Required permissions cannot be acquired.") Calling ACT Support directly was no help, as they redirected me to Microsoft Support. They apparently only have instructions for Sharepoint 2.0, not 3.0.
I pressed forward, including the web.config text noted in the ACT KB article 16514, but began to get further web.config errors when I'd refresh the site (IIS said that I was duplicating sections in the file). I then parsed the web.config file manually, dropping in code within existing headings (example: putting "<add name="Session" type="System.Web.SessionState.SessionStateModule"/>" within the existing "<httpModules>" listing rather than creating a new "<httpModule>").
This appeared to be my magic bullet, as the site loaded, but without any of the images on the opening spash screen. I pressed forward, ignoring warnings in ACT's Website Administration and defining a database connection without a valid impersonation account. I got in the system, but found other web.config errors when I attempted login from other browsers (Firefox, another copy of IE, etc.). Seeing that this obviously wasn't the final solution, I reverted to a saved copy of the web.config file, taking me back to where I was before I started screwing around.
Problem 2: I chose the proper domain from the dropdown in Website Administration and entered the credentials of 1) the new account I created, 2) my own Domain Admin-granted account, and 3) the overall Domain Administrator account. Nothing validated properly. I reverted to the new account and checked the ACT KB for suggestions. Fiddling with the registry key permissions at HKEY_LOCAL_MACHINE\SOFTWARE\AspNetProcess\ASPNET_SETREG didn't work, as they would revert any time I'd try to retest authentication within Website Administration. I also added this account to the IIS_WPG group, but that didn't work.
As I noted before, ACT Support has been less-than-helpful. I know there have to be other single-server users out there running Sharepoint 3.0 and ACT in harmony on a DC...
My only recourse now is to continue futzing with the installation on my DC or try a fresh installation on my accounting server. I'd really rather not do that, but if my current setup is impossible, then I'm painted into a corner.
10-10-2008 12:19 PM - edited 10-10-2008 12:19 PM
I've seen in many cases where installing on a DC with Sharepoint doesn't require any additional changes to the web.config file.
Please call into technical support so that one of your agents can assist you with the setup.
10-10-2008 01:17 PM
Thank you for your reply, but Tech Support already passed the buck to Microsoft regarding my issue. Seeing as I was running out of time, I moved ACT to my Accounting server after all.
However, I think my issue is NOT unique, as there must be plenty of others running newer versions of Sharepoint at their small business on a single server with ACT running in tandem. For those having problems, it might be best for ACT Support to update its knowledgebase with instructions on Sharepoint 3.
10-10-2008 04:38 PM
There are a couple of issues here.
1) I don't think your situation actually had a problem with Share Portal 3.0 honestly, rather the issue is with the domain controller.
2) ACT! Premium for Web warns you during installation on a Domain controller, mainly because the Microsoft SQL Express package that is installed is not recommended to be installed on a DC. To install SQL Express on a DC requires some specifics:
3) You are unable to set the Web administration up because it requires a local account, which there aren't any on a DC using active directory. True there are hacks you can do, but this is likely the reason you couldn't get this going.
True on detection of a DC, we could halt the installation of the Web product altogether, but that would alienate folks using Small Business Server 2003, which is also a DC, but a special configuration in which to host. So rather, we message indicating against installing on a DC.
Hope this is useful information.
10-21-2008 06:21 PM
On a DC, the impersonation account should be a member of IIS_WPG group (Domain Local) as well as Administrators and Domain Users.
Then give it the access as per KB 14867
Also, specifically give it access as per KB 21731 and also full control of the Database folder.
I usually create my own impersonation accounts, cause I like to mess with things... Have a read of this:
When you get that working, I always more the preferences to the ACT Data folder as it's easier to backup and administer as per KB 19770 - wish it did this by default
It's worth while (if you haven't) reading the admin guide from KB 23087
I do think it's more likely to be the DC impersonation that's the issue, but if it might be Sharepoint, maybe try these:
10-21-2008 06:54 PM
Re Sharepoint, you said you tried 16514... not sure if it's much different, but also see 16508
Sharepoint 2007 uses ASP.net 2.0. Previous versions of Sharepoint used ASP.net 1.1.APFW 2007 and later use ASP.net 2.0.
Installing any version of Sharepoint "takes over" the default website requiring additional configuration. If you want to run two versions of SP.net applications on the same website you must use the web.config file to set our virtual directory to use the right version of ASP.net.
Other possibilities would be re-creating the virtual directory under the new Sharepoint website and setting it to be excluded in Define Managed paths in he application management section of Sharepoint options
I also sometimes find it gets better results to stop all current SQL instance during install of APFW (SharePoint, backup, and you never know what else) - or even install in Selective Startup mode
Also, you said you tried Firefox... the ASP.Net requires IE - but, if you (as I do) prefer Firefox, this will work (but unsupported):