I am having a problem with WPS 7.0 SP2 Network Client install.

Network Specification as Follows:

WPS 7.0 SP2 installed to a Windows 2003 server.
The server is hardened to a Simi-Standard level 3 hardening.

WPSDIR = \\ServerX\Programs\Altiris\Wise Package Studio\
SHAREPOINT = \\ServerX\AppData\Wise\
Users have “Change” permissions to each of the Base Share Points.

Repository Server is a Windows 2003 server running SQL Server 2005.
WPS is to use a single SQL Server account, which is configured as DBO to All WPS 7.0 databases.
The Wise Repository Manager settings for each database object are as follows:
“Specify Logon information of a DBA, which is used to create Database(s):”
• SQL Server Authentication using a DBA Logon ID and Password.
“How Should user names and password be validated?”
• Windows NT authentication …..

Starting WPS the user receives the following error:
Microsoft SQL Server Login
Connection failed:
sql server error: 18456
[Microsoft][ODBC SQL Server Driver][SQL Server]login failed for user 'Domain\UserName'

Upon clicking the “OK”
The user is presented with the SQL Server Login, The UID is set for the SQL Account the Password field is blank and the Trusted Connection check box is checked.

If the user clears the Trusted Connection Check Box and enters the SQL Accounts password the user is then presented with the WPS Login Screen, which is the only one we want to appear.

A change of the Repository settings to ;
“How should user names and password be validated?”
• SQL Server authentication
Has no effect.

I have looked through the Altiris KB web site as well as the forums
I found two similar errors on the Forums but no solutions were posted.
I have also read all of the Wise install documents which offer no assistance.

Does any one have any ideas on this problem?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity



One other thing I missed from your other post, I recall an issue from years back where users actually required "Full" rights to the config.ini files and other ini files in the root of the sharepoint.

I dont know if this was resolved in later versions but worth checking as well.
Answered 08/20/2007 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment

If memory serves I think that was wise 3.x, but that seems like was forever ago I could be mistaken.

This is unfortunately a migration from a server resident WPS 5.6 to a server resident WPS 7.0. The user settings between the two servers are identical.

Answered 08/21/2007 by: Robo Scripter
Orange Senior Belt

Please log in to comment
I realize this is late in the game, but I just experienced the exact same issue, with the exact same sequence of SQL errors (Connection failed: sqlstate: '28000', sql server error: 18456), followed by the SQL server login. In my case, this happened for only one packaging engineer out of 12. For him, the UID field was also greyed out, and clicking on any of the other editable fields resulted in more SQL errors. I noticed that no one here or anywhere else (Symantec, Altiris, Juice, etc.) has posted a solution, so let me be the first.

The problem turned out to be: insufficient NTFS permissions on the Wise Share Point for that one user, caused by two factors: (1) he was not a member of an important global group that was given modify/write access to some of the subfolders under the WSP, and (2) permission inheritance was disabled on those subfolders. Until I had fixed both issues (adding his domain account to the group, and restoring permission inheritance on those subfolders), he kept on getting those SQL errors.

For anyone else out there with the same issue, this is what I recommend:

1) If you have a third-party tool that can determine the effective level of NTFS permissions for a folder, given memberships across multiple groups, use it. You can use that to compare non-working user A's access rights to working user B's, saving you much time on fruitless trial-and-error. Otherwise, use Microsoft Effective Permissions Tool. Also carefully compare A's AD group memberships to B.

2) Check NTFS and share permission settings on the two Wise shares (WSP & WPS) at the root, and through all subfolders (tedious, yes, but critical). Especially be on the lookout for instances where inheritance has been turned off (bad), and any groups or users with "Deny" access (which will override everything else).

If you do the above, I all but guarantee you'll find a discrepancy leading to an "a-ha!" moment and your solution.
Answered 02/18/2009 by: norexx
Orange Belt

Please log in to comment
I had issues with some SQL login. I solved it with changing the sql security to mixed mode.

In my case this was the error

A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=233&LinkId=20476

Hope it helps someone here.
Answered 02/19/2009 by: dvdzonenz
Purple Belt

Please log in to comment