Re: Event 1202 Warnings after Renaming Administrator Account on SBS200

I would actually just name it back, and give it a nice long and secure
password. Renaming is of little value. I'm not sure that renaming an account
would cause this error anyway.
What result do you get for Step 1 in the recommended steps?
Anthony
http://www.airdesk.com


"Dave2U" <Dave2U@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:67ADF26E-C8C1-4914-B110-B49A0F3239C0@xxxxxxxxxxxxxxxx
Hi Anthony,

Thank you for posting this reply. The policy setting flagged under the
Default Domain Controller's Policy is "Impersonate a client after
authentication". I'm not exactly certain of the purpose of this policy
setting/User Rights Assignment and the default setting for SBS2003. Since
I'm relatively new to SBS2003, I need to know the basic steps necessary to
change the account name to which this policy setting/User Rights
Assignment
applies?

I originally intended to post this question under the SBS group. However,
I
chose this group after noticing a considerable number of "spam" postings
under the SBS group [e.g. Dodge Vipers for sale, MI5 flames, etc.]
yesterday.
This group appears to be much better moderated.

Cheers!

"Anthony [MVP]" wrote:

You get this error when the specific account name that no longer exists
(in
your case Administrator) is referenced in a policy. This is typically a
User
Rights Assignment or a Restricted Groups policy. You need to find the
policy
and change the name of the account referenced from Administrator to
whatever
you renamed it as.
You might want to ask in the SBS groups for anything specific to SBS,
Anthony,
http://www.airdesk.co.uk






"Dave2U" <Dave2U@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F5553485-6110-4D00-9021-EEA06BEEB998@xxxxxxxxxxxxxxxx
As a security measure, I manually renamed the Administrator account on
an
SBS
2003 Premium R2 server. Since then, I have been receiving the
following
Event 1202 warnings every 5 minutes in the Application Event Log:
----------------------------------------------------------------------------------
Event Type: Warning
Event Source: SceCli
Event Category: None
Event ID: 1202
Date: 16/02/2008
Time: 2:45:57 PM
User: N/A
Computer: BVEPDCEX01
Description:
Security policies were propagated with warning. 0x534 : No mapping
between
account names and security IDs was done.

Advanced help for this problem is available on
http://support.microsoft.com.
Query for "troubleshooting 1202 events".

Error 0x534 occurs when a user account in one or more Group Policy
objects
(GPOs) could not be resolved to a SID. This error is possibly caused
by a
mistyped or deleted user account referenced in either the

User Rights or Restricted Groups branch of a GPO. To resolve this
event,
contact an administrator in the domain to perform the following
actions:

1. Identify accounts that could not be resolved to a SID:

From the command prompt, type: FIND /I "Cannot find"
%SYSTEMROOT%\Security\Logs\winlogon.log

The string following "Cannot find" in the FIND output identifies the
problem
account names.

Example: Cannot find JohnDough.

In this case, the SID for username "JohnDough" could not be determined.
This
most likely occurs because the account was deleted, renamed, or is
spelled
differently (e.g. "JohnDoe").

2. Use RSoP to identify the specific User Rights, Restricted Groups,
and
Source GPOs that contain the problem accounts:

a. Start -> Run -> RSoP.msc
b. Review the results for Computer Configuration\Windows
Settings\Security
Settings\Local Policies\User Rights Assignment and Computer
Configuration\Windows Settings\Security Settings\Local

Policies\Restricted Groups for any errors flagged with a red X.
c. For any User Right or Restricted Group marked with a red X, the
corresponding GPO that contains the problem policy setting is listed
under
the column entitled "Source GPO". Note the specific User

Rights, Restricted Groups and containing Source GPOs that are
generating
errors.

3. Remove unresolved accounts from Group Policy

a. Start -> Run -> MMC.EXE
b. From the File menu select "Add/Remove Snap-in..."
c. From the "Add/Remove Snap-in" dialog box select "Add..."
d. In the "Add Standalone Snap-in" dialog box select "Group Policy" and
click "Add"
e. In the "Select Group Policy Object" dialog box click the "Browse"
button.
f. On the "Browse for a Group Policy Object" dialog box choose the
"All"
tab
g. For each source GPO identified in step 2, correct the specific User
Rights or Restricted Groups that were flagged with a red X in step 2.
These
User Rights or Restricted Groups can be corrected by removing or
correcting
any references to the problem accounts that were identified in step 1.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
---------------------------------------------------------------------------------

I have stepped through the foregoing process and found the following
Policy
setting flagged in the Default Domain Controllers Policy: "Impersonate
a
client after authentication". I am also seeing Event ID Errors 107 &
1085
in
the Application log relating to Desktop folder redirection - these
errors
appear to be related.

I am able to successfully logon using the renamed Administrator account
and
perform tasks. My Administrator documents successfully replicated to
the
renamed account.

What steps can I take to resolve these issues? Do I need to restore
the
Administrator account temporarily and redo the rename using another
process?

Please advise. Thanks!





.