Event 1202 Warnings after Renaming Administrator Account on SBS200

February 18, 2008

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!

February 18, 2008

Re: Event 1202 Warnings after Renaming Administrator Account on SBS200

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

> 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!

February 19, 2008

Event 1202 Warnings after Renaming Administrator Account on SBS200

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

> > 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!

>

February 19, 2008

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@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

>> > 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!

>>

February 19, 2008

Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Event 1202 Warnings after Renaming Administrator Acct on SBS2003

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.

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

> >> > 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!

> >>

>

February 19, 2008

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

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.

>

> 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

>> >> > 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!

>> >>

>>

February 26, 2008

Event 1202 Warnings after Renaming Administrator Acct on SBS2003

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@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.

> >

> > 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

> >> >> > 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!

> >> >>

> >>

>

February 26, 2008

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

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.

>> >

>> > 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

>> >> >> > 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!

>> >> >>

>> >>

>>

February 26, 2008

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.

> >> >

> >> > 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

February 26, 2008

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Re: Event 1202 Warnings after Renaming Administrator Acct on SBS2003

Hi Dave,

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" <Dave2U@discussions.microsoft.com> wrote in message

news:1924F997-1590-4749-858E-5DD79E4D38E7@microsoft.com...

> 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.

>> >> >

>> >> > 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

Sign In

Event 1202 Warnings after Renaming Administrator Account on SBS200

Recommended Posts

Guest Dave2U

Popular Days

Popular Days

Guest Anthony [MVP]

Guest Dave2U

Guest Anthony [MVP]

Guest Dave2U

Guest Anthony [MVP]

Guest Dave2U

Guest Anthony [MVP]

Guest Dave2U

Guest Anthony [MVP]

Browse

Activity

Site Info