Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Hi Anthony,

Thank you for your continued follow-up on this file.

To address your specific questions:
1. Did I check Group Policies for references to the Administrator account? -
YES
2. Can I try renaming it back to see what happens? - Yes, but I'd prefer not
to at this point for reasons that will become clear below.
3. Did I make other changes at the same time? - NOT THAT I RECALL. The
changes I made initially related solely to renaming the AD profile after
enabling the Rename Administrator account policy in Group Policy. I'm still
researching documentation for any recommendations as to how to implement this
Best Practice of renaming the Administrator account on an SBS Server.
4. Do I have a Group Policy [enabled] to rename the Administrator account? -
YES. This Group Policy was implemented prior to renaming the Administrator
account.

This morning, I rechecked the Application Event Logs. Event 1202 warnings
stopped last night following my last changes and have not reappeared since.
So the issue now seems to resolve down to two errors in the Application Event
Log:

1. Folder Redirection Error - Event ID 107
Failed to perform redirection of folder Desktop. The folder is configured to
be redirected from <\\bvepdcex01\users\Administrator\desktop> to
<\\bvepdcex01\users\NewAdminName\desktop>. The following error occurred:
Access is denied.
For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
2. Userenv Error - Event ID 1085
Description: 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.

These errors appear every time I log on to the SBS2003 server - on the
console or via RDP. I have checked the Group Policy settings for Folder
Redirection and confirmed they are enabled. In summary, the Group Policy is
enabled as a Group Policy Object for BVE Users with the following settings:

Redirect MyDocuments>User Configuration[Enabled]>Windows Settings>Folder
Redirection>Settings
Group: DomainName\Domain Users
Application Data
Path: \\bvepdcex01\documents\users\%USERNAME%\Application Data
Desktop
Path: \\bvepdcex01\documents\users\%USERNAME%\Desktop
My Documents
Path: \\bvepdcex01\documents\users\%USERNAME%\My Documents

From the error message, it appears that only the "Desktop" portion of folder
redirection is failing - although I stand to be corrected on this. Thinking
out loud, here are some thoughts of mine that may shed some additional light
on this:

1. When I renamed the Administrator account, I wanted to keep the original
Administrator profile [Documents and Desktop] intact, lest I wanted to revert
for some reason. I suppose, I could have copied these two folders and placed
them elsewhere as backup copies that could be restored at a later date. As
it now stands, there are the following folders under C:\Documents and
Settings\:
administrator
administrator.DOMAINNAME
All Users
Default User
Local Service
Network Service
The following folders show up under D:\Documents\Users\:
NewAdminName
administrator's Documents
Application Data
Desktop
administrator
Application Data
Desktop
My Documents

2. I originally had the NewAdminName profile "pointed" at the Administrator
profile with full permissions to access the Desktop, Administrator Documents
and Application Data folders under the Administrator profile. I then
realized I needed to enable the "Rename Administrator" policy and then ran
through the "Rename User" wizard which changed the display name for the
Administrator.

3. There was one other change to group policy that a support tech for
Symantec Backup Exec walked me through which entailed modifying the Group
Policy settings for delegation to enabling "Trust computers and users for
delegation" under the Default Domain Controllers Policy. I believe this was
intended to allow Backup Exec services to run under the NewAdminName account
- which they now do. In retrospect, it might behoove me to create a
separate Backup Exec service account or have these services run as a Local
System account but that step will have to wait until after these issues are
resolved.

Since the NewAdminName has been assigned to the Domain Administrators and
Enterprise Administrators security groups, I am assuming these privileges
should be sufficient to create and/or modify folders in any location on the
server. The security permissions set on all folders noted above are as
follows:
Security: Group or user names:
Administrators (DOMAINNAME\Administrators)
- Full control <not inherited> This folder, subfolderes and files.
CREATOR OWNER
- Full control <not inherited> Subfolders and files only.
Username
- Full control <not inherited> This folder, subfolders and files.
SYSTEM
- Full control <not inherited> This folder, subfolders and files.

I hope this answers most, if not all, of your questions. Any assistance or
advice you might render would be most appreciated.

Cheers!

"Anthony [MVP]" wrote:

Did you check the Group Policies for references to the Administrator
account? Can you try renaming it back and see what happens? Did you make
other changes at the same time? Do you have a group policy to rename the
Administrator account?
For the redirection error: what policy do you have? and what is the exact
text of the message? Does the user mentioned in the error definitely have
the permissions to create a folder in the new location? Is this error just
occuring on the SBS server?
Anthony
http://www.airdesk.com




"Dave2U" <Dave2U@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C342C6FB-C3E9-4086-BEB7-48295025F5A7@xxxxxxxxxxxxxxxx
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
.

Relevant Pages

  • Re: The local policy of this system does not permit you to logon i
    ... Security policies were propagated with warning. ... Error 0x534 occurs when a user account in one or more Group Policy objects ... I have checked the security policies & the administrator profile is not ...
    (microsoft.public.windows.server.sbs)
  • Re: Lost XP User Account Settings
    ... file ownership and permissions supersede administrator rights. ... This is not your administrator account, ... Open Explorer, go to Tools and Folder Options, on the view tab, scroll to ...
    (microsoft.public.windowsxp.accessibility)
  • Re: Windows Media player(transfering files between user accnts.)
    ... file ownership and permissions supersede administrator rights. ... This is not your administrator account, ... >> Open Explorer, go to Tools and Folder Options, on the view tab, scroll to ...
    (microsoft.public.windowsxp.basics)
  • Re: Wheres the saved files from deleted users
    ... I know I did not try logging in as Administrator - can I do that? ... If you renamed the account to Board, that wouldn't have renamed the user ... profile folder; that would still be Bill Hepburn. ... However, if this is *your* user profile, it's very odd you can't see the ...
    (microsoft.public.windowsxp.general)
  • Re: Deleting Multiple Users
    ... You cannot log on to the Administrator account except in safe mode. ... The Windows folder in the David folder is nothing to worry about--it is ...
    (microsoft.public.windowsxp.setup_deployment)