scepol.log is over 80MB

[Dave]

I can't delete it and it won't defragment.

Windows 2K Server SP4, on a Dell PowerEdge 2550.

I found a registry change on the web to disable use of the file. After a
restart, the file is still locked.

Help!

 

[Jon Rabone]

I can't delete it and it won't defragment.
Windows 2K Server SP4, on a Dell PowerEdge 2550.
I found a registry change on the web to disable use of the file. After a
restart, the file is still locked.

I have the same problem; 212MB and growing at about 800KB / day. This is on
two different machines running Win2K SP4, but I don't think SP4 is the
problem; on one machine the earliest entry in "scepol.log" is May 2002.

I've checked the registry settings which are supposed to control debug
logging to this file (as per KB277675)

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\SecEdit\PolicyDebugLevel

is set to 0 (DWORD) on one machine, and not present at all on the other.

Is there another registry key or configuration setting that controls logging
to this file? It's starting to be a real pain - it's big enough to impact
backups, and fragmented across the disk.

Please Help!

(crossposted to m.p.w2k.general, m.p.w2k.group_policy and m.p.w2k.security -
please trim as appropriate)

Jon.

 

[Chris Corio [MSFT]]

This is a known issue. There is a fix that will be released in Windows 2000
SP5 and Windows 2003 SP1. Unfortunately, there is no current workaround.

Thanks,
Chris

 

[Nick Finco [MSFT]]

I don't believe the registry setting will work. This is a known issue for
both Win2k and Win2k3. It should be fixed in an upcoming service pack.

You should be able to force enough changes in SAM to cause SCE to rotate the
log. Once that happens, you can delete it from that directory. I haven't
tried this but it's worth giving a shot. Copy the script into a batch file
and run it. It will change your max password days to the SAME value that it
is currently set at. This doesn't change the machine's setting but it
should cause the log rotation path to be triggered. At 10 iterations, the
log will be rotated, at 20, the log will be rotated a second time and the
large logfile (which is the backup log at that point) will be deleted.

BTW, please post if this works for you.

N

<BatchScript>
@echo off

setlocal

set MAXPWAGE=

for /f "usebackq tokens=1,5" %%i IN (`net accounts`) DO (
if %%i.==Maximum. (
set MAXPWAGE=%%j
)
)

for /l %%k IN (1,1,10) DO (
net accounts /MAXPWAGE:%MAXPWAGE%
)

Endlocal
</BatchScript>

 

[Nick Finco [MSFT]]

An update to my previous post. That script doesn't quite work. Unless the
value is changing, the events won't be triggered. Here's an updated script
that I just used on my DC to rotate that log out. I mentioned that 20
iterations will rotate the log out. It will only do that if the new log was
over the 1Mb log file threshold. So run the script as is (10 iterations)
and then go delete the large logfile.

!!!This will set your max password age to a setting other than your current
setting!!! It will determine your current setting, and then alternate
setting your max password age between your current value + 1 and your
current value. It will finish by setting it back to your current value so
you shouldn't see any issues. Because it increments the value, domain users
won't have the new value applied to them.

N

<BatchFile>
@echo off

setlocal

set MAXPWAGE=

for /f "usebackq tokens=1,5" %%i IN (`net accounts`) DO (
if %%i.==Maximum. (
set MAXPWAGE=%%j
)
)

if NOT defined MAXPWAGE goto ErrorIt
set /A MAXPWAGEPP=%MAXPWAGE%+1


for /l %%k IN (1,1,5) DO (
net accounts /MAXPWAGE:%MAXPWAGEPP%
net accounts /MAXPWAGE:%MAXPWAGE%
)


goto EndIt
:ErrorIt

echo ERROR!!!

:EndIt

Endlocal
</BatchFile>

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm