Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Hi Anthony,

I'm sorry it's taken several days to get back to you - life gets in the way
sometimes!

I investigated all the local security policies on the machine and found only
one referencing the original administrator account: "Impersonate a client
after authentication". This should come as no surprise since it was this
specific policy setting that was flagged with a big, red "X" when I stepped
through the diagnostic phase.

I removed the original administrator account from this policy setting and
replaced it with the renamed administrator account [although, come to think
of it, this should probably just be changed over to the administrators group
- perhaps saving some grief and aggravation for the next IT guy after me.

I also checked all scheduled tasks and services to ensure none were
referencing the former administrator account. None were. I then returned to
review the settings under the Default Domain Controllers Policy. I was
presented with a pop-up message that stated: "The Permissions for This GPO in
the SYSVOL Folder Are Inconsistent with Those in Active Directory" Message
When You Run GPMC" and referencing the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;828760.

I took a gamble and clicked on "Okay" to change the permissions in SYSVOL to
match those in AD. I followed that by running GPUpdate /force.

When I logged back into the machine, it appeared that the policy changes I
made took hold. However, a check of the event logs indicates that the 1202
event errors seem to have stopped, but I am still seeing 107 [Folder
Redirection] and 1085 [Userenv] errors in the Application Event log.

Your thoughts?

Cheers!

"Anthony [MVP]" wrote:

Hi Dave,
In answer to your questions:
1) Hunt down in the local security policies (Administrative tools) where the
Administrator account is referenced. Hunt down in scheduled tasks, group
policies and runnning services where the account may be being used.
2) I don't think there is a correct procedure, although in an SBS
environment there may be a few specific things to check. It is only SBS that
sets all these things up automatically for you. Everywhere else you would
not use the Administrator account for anything.
Anthony
http://www.airdesk.com


"Dave2U" <Dave2U@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0FC7A516-06E6-4717-8712-0AEF849D631B@xxxxxxxxxxxxxxxx
Hi Anthony,

As I continue my investigations, I've learned that account settings are
retained in two locations - Active Directory and Global Policy.
Evidently,
there is a correct procedure that uses Global Policy to rename the
Administrator account.

Apparently, I used an incorrect [manual] procedure to rename the
Administrator account that consisted of simply modifying the AD properties
and security settings on the Administrator profile to change ownership
from
"Administrator" to "NewAdminName". I left the primary email address for
"NewAdminName" as "Administrator@xxxxxxxxxxxx".

I have full access to the Administrator's "My Documents" folder via the
NewAdminName's "My Documents" folder. So at least that much is working.
However, on login, I am seeing a Folder Redirection Error [Event ID 107]
that
tells me it failed to perform redirection of the folder Desktop. The
folder
is configured to be redirected from
<\\bvepdcex01\users\Administrator\desktop> to
<\\bevpdcex01\users\NewAdminName\desktop>. The following error occurred:
Access is denied. For more information, see Help and Support Center at
http://go.microsoft.com/fqlink/events.asp.

This is followed by Userenv Error Event ID 1085 that tells me the
following:
The Group Policy client-side extension Folder Redirection failed to
execute.
Please look for any errors reported earlier by that extension. For more
information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

When I perform Step One of the recommended steps below, I get the
following:
C:\>FIND /I "Cannot find" %SYSTEMROOT%\Security\Logs\winlogon.log

------------- C:\WINDOWS\SECURITY\LOGS\WINLOGON.LOG
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.
Cannot find administrator.

C:\>

So, in short, I am seeking a couple of things from this:
1. The most effective way to eliminate these error messages/events while
retaining the NewAdminName for the primary Administrator account.
2. Specific guidance as to the "correct" procedure for renaming the
Administrator account so as to avoid this ordeal in the future.

Your suggestion for using a long passphrase for the Administrator account
is
appreciated - it being much simpler to change a password than to rename an
account. However, subscribing to the "belt and suspenders" approach when
it
comes to security, there is less likelihood of one being caught with their
pants down, so to speak, when the well known and targeted administrator
account is properly renamed and a complex passphrases are employed across
the
board.

Cheers,



"Anthony [MVP]" wrote:

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!









.