 RE: Proxy account set up
Hi Alex,
This following is a summary of initial troubleshooting steps for the "Error
executing extended stored procedure. Specified user cannot login." message.
0)
Start|Run|cmd.exe and type the following two lines:
CD C:\
SET
If SET returns a LOGONSERVER value that is the local box's name (as opposed
to the name of a domain controller) then you are logged onto this box using
cached credentials and instead this box needs to logon to the domain (and
rebooting the box may cause the logon server to now more appropriately be
the domain controller). If no reboot is needed (because the LOGONSERVER is
set to a Domain Controller) then keep the command prompt window open (as
it's needed in step 4).
1)
Verify that the startup account for SQL Server and SQL Agent services are
NT
domain accounts and are member of the local administrators group.
2)
Verify that the startup account for SQL Server and SQL Agent services have
the
following rights
Act as part of the Operating System
Increase Quotas
Log on as a Service
Replace a process level token
Log on as a batch Job
(per http://msdn.microsoft.com/library/e...erview_6k1f.asp)
3)
Verify that the account that you want to use for "SQL Agent proxy account"
has the "Log on as a batch job" right. If not, then assign it the right
using the instructions in step 2.
4)
After recycling SQL Server (because advanced rights only take effect when a
service/account logs in), do the following:
Log on locally to the SQL Server using the startup account of SQL Server
service
Open Query Analyzer and run the command
EXEC master.dbo.xp_sqlagent_proxy_account
N'SET',N'domain_name',N'user_n
ame',N'password'
If this still fails with the error "Error executing extended stored
procedure:
Specified user can not login", do the following:
Copy the attached whoami.exe to C:\, go back to the command prompt (opened
in step 0, you may want to check the LOGONSERVER again <g> ) and type the
following command (at the C:\> )
WHOAMI/ALL>c:\whoami.txt
(note that there is a *total lack* of spaces within the above command <g> )
Inspect whoami.txt and compare with the advanced rights (mentioned above).
There are other causes of a domain controller failing to authenticate (or a
domain controller not being able to authenticate) an account, such as
networking issues, name resolution issues, etc. You can post whoami.txt if
you wish (so I can inspect it <g> ), and/or I may have other utilities that
may assist should you get to this point without a resolution. But, it would
perhaps be better (if unresolved at this point) to open a support case
because further troubleshooting steps can become complicated and/or require
your (and our) undivided attention <g>.
RE Running DTS packages: It sounds as though you are aware of
http://support.microsoft.com/defaul...B;EN-US;269074, but I
thought I would mention it anyway <g>. For example, a user who creates a
DTS package that in turn references a mapped drive (for that user) may
become perplexed <g> when a scheduled run of that package cannot find that
very same mapped drive (likely because the Proxy account doesn't have that
same drive mapped to the same location). Further details and 'gotchyas' are
within that article.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
This posting is provided "AS IS" with no warranties, and confers no
rights. Subscribe to MSDN & use http://msdn.microsoft.com/newsgroups.
 Attachment:
This has been downloaded 0 time(s).
Report this post to a moderator
|
12-05-02 11:23 AM
