Post reply

Pre-Windows 2000 Compatible Access Group

  • September 15, 2005 at 10:06 am

    #91190

    How can you tell if the Windows 2000 Compatible Access Group has been installed on SQL Server?

    How can you tell what version of SQL Server 2000 you are running?

  • September 15, 2005 at 11:04 am

    #590247

    1)What is Windows 2000 Compatible Access Group ?

    2)Sql server version:

    SELECT @@VERSION

    or

    xp_msver (see books on line)

  • September 15, 2005 at 11:09 am

    #590248

    Or try:

    SELECT CONVERT(VARCHAR(20), SERVERPROPERTY('ProductLevel')),

    CONVERT(VARCHAR(20), SERVERPROPERTY('ProductVersion'))

    -SQLBill

  • September 15, 2005 at 11:44 am

    #590276

    Pre-Windows 2000 Compatible Access Group is an upgrade. It is necessary if your receiving the following error:

    The job failed. Unable to determine if the owner (domain\username) of job testjob has server access (reason: Could not obtain information about Windows NT group/user 'domain\username'. [SQLSTATE 42000] (Error 8198)).

    See article link below for full details.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;241643

    I just want to know how can you tell if it has been installed?

  • September 15, 2005 at 7:19 pm

    #590409

    Why ? Why not just change the job owner to reflect the environmental change brought about by the domain "upgrade" ? To "sa" perhaps even...

    It's a Windows group so you could make an applet to check for the group's existence or do  "NET GROUP /DOMAIN" from the dos prompt to list all groups. (Look at syntax help)

    DB

     


    The systems fine with no users loggged in. Can we keep it that way ?br>

  • September 16, 2005 at 6:54 am

    #590536

    This is from a referenced KB article:

    Set Up the 2000 Compatible Access Group in the Active Directory Users and Computers Snap-in

    By default, the Everyone special group is a member of the Pre-Windows 2000 Compatible Access group. This enables any RAS caller to be authenticated by the Windows NT 4.0 RAS server. If the Everyone special group has been deleted from the Pre-Windows 2000 Compatible Access:

    1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
    2. In the console tree, click the server you want to work with.
    3. In the console tree, click the BUILTIN folder.
    4. In the Details pane, right-click the Pre-Windows 2000 Compatible Access group, and then click Properties.
    5. On the Members tab, click Add.
    6. In the Select Users, Contacts, Computers or Groups dialog box, click the Domain Users group, click Add, and then click OK.
    7. After you verify that the group has been added, click OK.

    So, it looks like you go to Active Directory Users and Computers and find out there if this has been done.

    -SQLBill

  • September 16, 2005 at 6:56 am

    #590540

    Whoops...it looks like first you have to set up that group in Active Directory, then you need to add the group to you SQL Server logins (Security>Logins).

    -SQLBill

  • September 16, 2005 at 8:10 am

    #590604

    This group is in AD by default, just change to advanced view...

    But you don't need to do this!

    What happens is that the domain account for SQL server can not read user attributes in AD, though it can reaad OU and containers attributes. Pick a user, drill down into permissions, probly advanced view as I recall, and you will find that the "Pre Windows..." group has blanket read access across AD. It can read everything.

    The correct article for 8198 errors is this: http://support.microsoft.com/default.aspx?scid=kb;en-us;834124

    This group is a kludge for old legacy apps to work... but there are alternate methods...

    1. A post SP3a hotfix alleviates the problem sometimes (linked from 834124) http://support.microsoft.com/kb/830596  This is in SP4. xp_logininfo is called silently by SQL Agent and xp_sendmail, this is where the error lies.

    2. Windows 2003 AD introduced more controlled and limited builtin security principals because of this: read this for background http://support.microsoft.com/default.aspx?scid=kb;en-us;331951 and add the service account into the new group

    3. If it still fails, use teh "pre-windows..." group, but not until then.

    FFS! Don't just change your AD to grant blanket rights based on old KB articles and lack of research!

    You get this error if you have tightened AD Security and Group Policy and are running SQL in restricted domain user account. Run it as local system or domain admin and you have no issues. So why open it all up using a kludge left in AD for legacy...

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply