Have you tried attempting to start the ARS Server service and then examining the SQL logs in Enterprise Manager to see if the logon attempt succeeded or was even attempted?
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Watson, Benjamin A. Sent: Tuesday, October 02, 2007 9:28 AM To: arslist@ARSLIST.ORG Subject: Re: ARServer fails to connect to new database server Thanks Norm, however we're not using that account (ARAdmin) to connect to SQL anymore. What we really have is three separate Remedy environments (Development, Test, "Pseudo-Production") in our development environment, all sharing the same database server with individual Remedy databases. For each database, we created unique SQL logins corresponding to each database. Each Remedy instance connects to their respective databases using their own SQL account. Typically, whenever we restore a backup, we use SQL stored procedures to reset the database owner to 'sa', then back to the original owner. This has all worked like a charm in the past (for years). Now, we've got a new "box" (I quote box because these are all virtual machines) and a fresh install of SQL 2005 on it. I manually created all of the database logins, then restored each DB and reset the db owner for each db to these appropriate logins. At first, I wondered if it was because our new SQL box isn't "exactly" a replica of our previous SQL box. Our previous box had a unique network hostname name, was a member of the Windows Domain, and ran SQL server as a domain user. This new box isn't on the domain (but has the same hostname name) and is running SQL as a system account. Of course, I ensure only one SQL server box is on at a time to prevent hostname conflicts on the network. To that end, I had our network admin remove the "old" box from the domain and add the "new" box. Still nothing. I now am leaning towards a SQL issue on the new box as I've done the following: 1. Powered down the "new" SQL box 2. Powered up the "old" SQL box 3. Pulled the "old" box off the domain 4. Rebooted "old" box (don't you just love messing with hostnames/domains?) 5. Logged back into "old" box and saw errors galore because SQL couldn't start as the domain account (go figure) 6. Used SQL config manager to set all SQL related services to running as a local system account 7. Started SQL 8. Manually pointed the AR Server to this "old" box by modifying the host file as the DNS now points to the "new" (powered down) SQL box. 9. Started AR Server 10. Could successfully connect/login! So, at this point, I'm at a bit of a loss. I can basically take the application server out of the equation (it still works on the "old" box that is not on the domain and running SQL as a system account). I can't really "stare and compare" the two database servers as I can't have them powered up on the network at the same time. But from everything I've seen, they're pretty much identical with respect to how SQL server is configure, the SQL accounts, and the databases. The only thing I can see now is that both SQL servers are configured for "mixed mode" (SQL and Windows) authentication. On the "old" box, I can see SQL logins corresponding to Windows domain accounts that each of our Remedy instances run as (Remedy runs as a Domain account for the sake of sending e-mail). On the "new" box, I don't see those SQL logins for those domain accounts, just the SQL logins I created. Perhaps I'll attempt to run the "new" SQL server as a domain account, then access it using the other Remedy domain accounts to establish those logins. Ben ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
