R
Rob C via WinServerKB.com
I am getting multiple instances of the following in one of my T/S application
logs:-
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1000
Date: 19/12/2005
Time: 01:43:19
User: NT AUTHORITY\SYSTEM
Computer: *********
Description:
Windows cannot determine the user or computer name. Return value (1359).
and this will be followed by:-
Event Type: Information
Event Source: SceCli
Event Category: None
Event ID: 1704
Date: 19/12/2005
Time: 02:08:09
User: N/A
Computer: ***********
Description:
Security policy in the Group policy objects are applied successfully.
and then again followed by multiple logs of the previous message
The messages displayed here were sequential in the log
I have done some research and found that the 1704 event is happening
'roughly' in time with the MaxNoGPOListChangesInterval Registry key. This
key is set to the Standard 16 hours (960 minutes). Although this may be a
big fat red herring.
For all intents and purposes, the policy settings are being applied but now
the messages are starting to gain speed. I have also noticed that we cannot
view any users for this server using the Terminal Services manager console as
it just hangs with a yellow question mark as if it can't gather the info....
this is from an admin connection to the TS concerned!! All other S enabled
servers are able to report back with no problems and i can view/interact with
the users that it finds.
It looks similar to a problem we had recently with what we think was a memory
leak that was brought on through setting a PagedPoolSize limit to the maximum
that it could be as apposed to the standard 0 that would work out what it
needs automatically. This was stopping users using thier roaming profile and
was also reporting that the registry memory size was too small. We have no
idea why the PagedPoolSize reg setting was set to the 192Mb max but it was so
we changed it to 0 and that stopped the users having issues but brought on
the messages above.
Previous to the event above, there was also a problem with the paging file
becoming corrupted and being stuck on 20MB. We sorted that by setting the
file to 0 and 0 and then rebooting and then resetting it to what we wanted.
Any ideas because i cannot find squat didly on the internet about it!!....Do
microsoft need to know??
Cheers for any help offered!!
logs:-
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1000
Date: 19/12/2005
Time: 01:43:19
User: NT AUTHORITY\SYSTEM
Computer: *********
Description:
Windows cannot determine the user or computer name. Return value (1359).
and this will be followed by:-
Event Type: Information
Event Source: SceCli
Event Category: None
Event ID: 1704
Date: 19/12/2005
Time: 02:08:09
User: N/A
Computer: ***********
Description:
Security policy in the Group policy objects are applied successfully.
and then again followed by multiple logs of the previous message
The messages displayed here were sequential in the log
I have done some research and found that the 1704 event is happening
'roughly' in time with the MaxNoGPOListChangesInterval Registry key. This
key is set to the Standard 16 hours (960 minutes). Although this may be a
big fat red herring.
For all intents and purposes, the policy settings are being applied but now
the messages are starting to gain speed. I have also noticed that we cannot
view any users for this server using the Terminal Services manager console as
it just hangs with a yellow question mark as if it can't gather the info....
this is from an admin connection to the TS concerned!! All other S enabled
servers are able to report back with no problems and i can view/interact with
the users that it finds.
It looks similar to a problem we had recently with what we think was a memory
leak that was brought on through setting a PagedPoolSize limit to the maximum
that it could be as apposed to the standard 0 that would work out what it
needs automatically. This was stopping users using thier roaming profile and
was also reporting that the registry memory size was too small. We have no
idea why the PagedPoolSize reg setting was set to the 192Mb max but it was so
we changed it to 0 and that stopped the users having issues but brought on
the messages above.
Previous to the event above, there was also a problem with the paging file
becoming corrupted and being stuck on 20MB. We sorted that by setting the
file to 0 and 0 and then rebooting and then resetting it to what we wanted.
Any ideas because i cannot find squat didly on the internet about it!!....Do
microsoft need to know??
Cheers for any help offered!!