Event 1202 Warnings after Renaming Administrator Account on SBS200
Dave2U
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!
Anthony [MVP]
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" <Dav...@discussions.microsoft.com> wrote in message
news:F5553485-6110-4D00...@microsoft.com...
Dave2U
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]
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" <Dav...@discussions.microsoft.com> wrote in message
news:67ADF26E-C8C1-4914...@microsoft.com...
Dave2U
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 "Admini...@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]
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" <Dav...@discussions.microsoft.com> wrote in message
news:0FC7A516-06E6-4717...@microsoft.com...
Dave2U
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]
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" <Dav...@discussions.microsoft.com> wrote in message
news:C342C6FB-C3E9-4086...@microsoft.com...
Dave2U
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]
It is a bit hard to untangle. I would just try to back out the changes you
have made. There is no need for the Administrator account to have a roaming
profile or redirected folders, as you should not log on with it in normal
usage. You can do a backup if you are worried about losing anything.
When you have backed everything out, then if you wish you can just set the
policy to rename the account although it is not really necessary or useful.
The name is just a label attached to the real identity, which is the SID of
the account. The SID stays the same when you rename, and therefore has
access to the private folders of the account regardless of the name.
Sorry I can't be more help. You may be able to repair it with a few more
changes, but it is harder to follow than just backing out and starting
again,
Anthony
http://www.airdesk.co.uk
"Dave2U" <Dav...@discussions.microsoft.com> wrote in message
news:1924F997-1590-4749...@microsoft.com...