Client Logon error
Updated: 22 May 2010 | 8 comments
This issue has been solved. See solution.
Hi,
We've installed WPS 7.0 SP3 onto a new 2003 member server as a particular service account and created the 3 DB's on a dedicated SQL server using Windows Auth.
Next we installed WPS on a Windows XP desktop and opened up WPS and tried to logon but we get a SQL connection error.
We've tried logging on as the "Admin" account and the Service account used to install the product but to no avail.
The documentation that comes with the product is rather poor to say the least and I can't find anything on the web to point us in the direction of creating user accounts etc?
Attached is the logon error...
discussion Filed Under:
Comments
Zzzzzzzzzzzz....
Zzzzzzzzzzzz.... support.microsoft.com/kb/555332
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
No Gold star
The SQL server is already in Mixed mode.
Ah, I see.
Ah, I see. We should have *known* that the text "We've <snip> created the 3 DB's <snip> using Windows Auth." was there purely to throw us off the scent.
Every single mention of that error message that I could find advises that the server needs to be in mixed mode so, if you're saying that it's already set up that way, I'm out.
You'll find it quicker to debug if you use the ODBC Control panel applet, rather than have the bulk of WPS in the way.
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
Who created the three DB's ?
If you had *mentioned* that the SQL server was already in mixed mode, perhaps VBScab would have suggested something different.
Anyway, you mention setting up the three DB's, implying that this was done manually rather than by allowing the WPS install to handle it. If that is the case, then delete everything and start again, and this time allow WPS to set up the databases in their entirety.
If you DID allow WPS to set up the databases, have you run Repository Manager to correctly configure the databases?
In addition, have you opened ODBC manager on the test workstation and verified that the two ODBC connections are able to communicate with your SQL server?
If you continue to have problems, the Altiris KB has a tech note on how to set up SQL Server Express 2005 to act as the database for WPS - you may wish to try following these instructions on your WPS server and see if you can get that running - at least this will give you a sanity check on your environment.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Resolved
WPS on the Server was connecting to the DB's using Windows Auth with the account used during the install.
The "Packaging" workstation wasn't a member of the domain so I just changed the ODBC connection to SQL auth and hey presto we're connected.
Another way of course would have been to assign rights to the WPS DB's to a Windows group and get the user to logon to the workstation as a member of that group but apparently most packaging machines are not generally members of a domain?
Anyhow, we're all set now.
Thanks for pointing me in the right direction, and I realise it was a simple post and I should have worked it out but I think I too was thrown off the scent by the "Service Account" used during the initial set-up.
Guess I'll have to read up some more as to how the Wise Server talks to the DB server. - Windows accounts, WiseSvc generic accounts etc.
Read the "Getting Started Guide"
The license information is stored in the profile of the user account that was used to install the software. If you are running with just a single license, then there is really no point in having a server install for WPS, unless the packager is going to use the server as their packaging workstation, or you are going to use the web based functionality from the server.
Otherwise, just install the software in "server" mode on the packager's test workstation and specify the SQL server you have set up. Make sure the install takes place with the admin account that will be used for packaging. Run repository manager and check the databases are OK. Then go package.
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
>apparently most packaging
>apparently most packaging machines are not generally members of a domain?
I don't know why that would be. In the majority of environments I've worked in, w/s *are* part of the domain but have the default machine and/or user policies filtered out.
Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.
My experience also
At almost all client sites I have worked with, the packaging machines are part of the domain. Sometimes a dedicated domain for the packaging team but neverthess a representative setup mirroring the production domain.
How can you hope to do realistic testing of your packages unless your test environment is as close as possible to the production environment in the way it is set up?
If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.
Would you like to reply?
Login or Register to post your comment.