Event 1202 Warnings after Renaming Administrator Acct on SBS2003
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@discussions.microsoft.com> wrote in message
> news:C342C6FB-C3E9-4086-BEB7-48295025F5A7@microsoft.com...
> > 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@discussions.microsoft.com> wrote in message
> >> news:0FC7A516-06E6-4717-8712-0AEF849D631B@microsoft.com...
> >> > 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@MyDomain.com".
> >> >
> >> > 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@discussions.microsoft.com> wrote in message
> >> >> news:67ADF26E-C8C1-4914-B110-B49A0F3239C0@microsoft.com...
> >> >> > 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@discussions.microsoft.com> wrote in message
> >> >> >> news:F5553485-6110-4D00-9021-EEA06BEEB998@microsoft.com...
> >> >> >> > 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