Microsoft KB Archive/318632

= FIX: SQL Debugging may fail because of a strict local password complexity policy =

Article ID: 318632

Article Last Modified on 1/20/2006

-

APPLIES TO


 * Microsoft Visual Studio .NET 2002 Enterprise Architect
 * Microsoft Visual Studio .NET 2002 Enterprise Developer
 * Microsoft SQL Server 2000 Standard Edition

-



This article was previously published under Q318632



SYMPTOMS
When you install the products listed in the &quot;Applies to&quot; section of this article, and then you run Visual Studio .NET in a Windows Terminal Services session, you may not be able to use the SQL Debugging features. No error occurs but the debugger does not step into the stored procedure.

However, when you run Visual Studio .NET on the interactive desktop (local console), T-SQL Debugging works as expected.



CAUSE
When the SQL Debugging feature is installed, a special account called SQLDebugger is created. This account is used as the identity under which the SQL Debugger Registry2 DCOM server process (Sqldbreg2.exe) runs.

The SQLDebugger account is created with a strong random password for security purposes. If this password does not comply with the effective local password complexity policy, the SQLDebugger account is not created and the DCOM server is registered to run under the Interactive User account. This prevents the SQL Debugging feature from working correctly when you run Visual Studio .NET in the Terminal Services client session.



RESOLUTION
To determine whether you are experiencing this particular problem, verify that a local account named SQLDebugger exists. If the account does not exist, you probably are experiencing this problem.

To resolve the problem, follow these steps:  Create a new local account named MySQLDebugger. Make the account a member of the Users group (a default setting). Set the User cannot change password and Password never expires attributes for this account. Configure the DCOM Server named SQL Debugger Registry2 to run with the MySQLDebugger account as its identity, instead of the Interactive User account. To do this, follow these steps:  On the Start menu, click Run. Type DCOMCNFG, and then click OK.</li></ol> </li> To open the Identity tab of the Properties dialog box for SQL Debugger Registry2, follow the steps for your operating system: <ul> On a computer running Windows 2000, do the following: <ol style="list-style-type: lower-alpha;"> The Distributed COM Configuration Properties dialog box appears. On the Applications tab, click SQL Debugger Registry2 in the list, and then click Properties.</li> In the Properties dialog box, click the Identity tab.</li></ol> </li> On a computer running Windows XP, do the following: <ol style="list-style-type: lower-alpha;"> After you run DCOMCNFG, the Microsoft Management Console (MMC) snap-in for COM+ appears. Expand COM+, expand Computers, expand My Computer, and then expand DCOM Config.</li> Click the SQL Debugger Registry2 node. Right-click the node, and then click Properties.</li> In the Properties dialog box, click the Identity tab.</li></ol> </li></ul>

NOTE: If SQL Debugger Registry2 does not appear in the list of registered DCOM servers, you may not have installed the SQL Debugging feature of the product.

</li> On the Identity tab, click to select This User.</li> Type MySQLDebugger for the user name, type the password, confirm the password, and then click OK.</li></ol>

<div class="status_section">

STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article. This bug was corrected in Visual Studio .NET (2003).

Keywords: kbtshoot kbbug kbfix kbvs2002sp1sweep kbvs2005swept kbvs2005doesnotapply KB318632

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.