IE7 IEAK upgrade causes all Internet Zones to be treated as Local Intranet

Ah, yes, this bug again. I've seen it crop it's nasty head up a number of times all the way back to IE 4.x.

After using an IEAK upgrade to upgrade my stations from IE6 to IE7, Internet Explorer treats all Internet sites as Local Intranet. For me, this means they have additional rights to install spyware & because we don't allow passwords to be saved on our Intranet via a GPO, the users can't save ANY of their passwords for any website.

I've seen this times before. So I had a hunch. I checked my settings. Everything seems right in the GUI. The settings match my machine. Mine was updated via WSUS, not through IEAK installer. But we both run the same .INS configuration file. We run security zones for IE as HKLM only as described in KB182569. This allows us to set the settings once per PC and be done.

So my first test was to disable "Automatically Detect Intranet settings". And behold, the Internet zone was detected correctly now. Go back into the settings and IE7 had reset this setting back to enabled. But that didn't matter, the detection was working now. I tested this on 3 machines and repeated the experience.

So I found the registry location and dumped it into a .REG file

REGEDIT4

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap]
"AutoDetect"=dword:00000000

Notice this is in the HKCU location and not the HKLM location, where my settings should be coming from. However, running this via REGEDIT /s ie7fix.reg in a login script resolved the issue on 3 machines. So this triggers IE to fix whatever is wrong. Since my settings come out of HKLM, the IE GUI still shows autodetect enabled. And it detects correctly.

This is obviously a bug. IE7 must not be looking at HKLM in every case where it should when Security_HKLM_only is enabled. My guess is that the IEAK installer couldn't access the HKCU hive of the user. Somehow setting the AutoDetect value in HKCU triggers IE7 to fix what is wrong there.

--- Correction below----

This was caused by my own doing. I followed these directions;
http://www.msfn.org/board/index.php?showtopic=75475&mode=linearplus

Which had me set the runonce to 1 so that the annoying welcome to IE7 didn't appear. Apparently it is this flag that also upgrades HKCU settings from IE6 to IE7. So I caused the problem myself.

Ubuntu, Cron, Logrotate, and Squid

So you have that nice new Ubuntu server running. You get Squid up and configured, and have it using an effective user and group of squid. But each day at the same time, the squid server just stops. The logs show that it can't write to access.log. You take a look at /var/log/squid/access.log and find out that the file is owned by root:root. So it's an ACL issue.

You modify logrotate for squid adding chown and get squid back up. But the next day it fails. What gives?

Ubuntu 6.0.6 runs a cron job daily /etc/cron.daily/sysklogd. This archives your log files to save disk space and rotates them, independent of logrotate. If you look at this, you'll see it does a chown root:adm. Ooops.

So modify sysklogd to have this at the end;

touch /var/log/squid/access.log
chown --silent squid:squid /var/log/squid/access.log
chown --silent -R squid:squid /var/log/squid/access*
test ! -e /var/run/squid.pid || /usr/sbin/squid -k rotate

Of course, if you use a different user:group than squid:squid, replace with what you use. The last line gets squid to start logging into the new access.log, versus access.log.0.

Enjoy.

Forcing a PC to reboot through task scheduler

So you want to schedule a PC to reboot through the task scheduler. It works sometimes, but not every time. Microsoft has created multiple shutdown commands. Below is a batch file which seems to work 100% of the time in my environment. We use the built in XP shutdown command first, then the old NT4 resource kit shutdown command, then again try the XP.

It seems that sometimes during shutdown, a program will hang the process. These additional shutdown commands seem to get it past that.

rem Reboots this PC

shutdown -r -t 90 -f -c "Nightly reboot occuring in 90 seconds to apply patches"
shutdown2 /L /R /T:160 /Y /C "Nightly reboot occuring in 90 seconds to apply patches"
shutdown -r -t 60 -f -c "Nightly reboot occuring in 90 seconds to apply patches"
sleep 100


Sometimes I stick sleep commands between the shutdowns. I don't fully understand this issue, but the above batch file works for me.

Fixing WSUS for all the various reasons.

So you cloned a PC and it has the same WSUS GUID. Sysprep didn't help.
Or you put a volume license onto an OEM, and now WSUS fails.

Whatever the reason, here is the batch file to fix it.


net stop wuauserv
rem Transflo depends on BITS and must be stopped first
net stop "TRANSFLO Client Agent Service"
@rem one known dependent service. Add others you know of.
net stop "Background Intelligent Transfer Service"

@rem Make sure the proper GPOs are applied
gpupdate

@rem re register services that may be broken

REGSVR32 /s WUAUENG.DLL
REGSVR32 /s WUAUENG1.DLL
REGSVR32 /s ATL.DLL
REGSVR32 /s WUCLTUI.DLL
REGSVR32 /s WUPS.DLL
REGSVR32 /s WUPS2.DLL
REGSVR32 /s WUWEB.DLL

REGSVR32 /s ATL.DLL

rem Remove the temp directories.

rd %windir%\SoftwareDistribution\DataStore\logs /s /q
rd %windir%\SoftwareDistribution\DataStore /s /q
rd %windir%\SoftwareDistribution\Download /s /q
rd %windir%\SoftwareDistribution\EventCache /s /q


rem Some machines will fail to re-install MSI 3.1 after
rem all of this. About 1%. The fix is below.
rem It is up to you to determine if you want to download
rem and install these fixes. Remmed out.

rem call WindowsXP-KB927891-v3-x86-ENU.exe" /quiet /norestart
rem call Windows2000-KB927891-x86-ENU.EXE" /quiet /norestart

regedit /s resetGUID.reg

net start wuauserv

wuauclt /resetauthorization /detectnow



---------------------------------------------------------------
Here is the resetGUID.reg file
---------------------------------------------------------------
REGEDIT4

// Registry file generated by the Application Launcher.

[HKEY_LOCAL_MACHINE\SOFTWARE]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate]
"AccountDomainSid"=-
"PingID"=-
"SusClientId"=-







I've ran this on hundreds of machines with no problem. This is provided as-is. I provide no warranty.

Example code in VB to set color of subitems

Here is code that rips through a file to set the color of a listview item color and subitem color.

This is VB6. I found a lot of people asking how to do this, but no real solutions. It's not that hard after you know what the syntax is;


Do Until EOF(fnum1)
Line Input #fnum1, Linein
aRRy = Split(Linein, ",")
If UBound(aRRy) = 10 Then
SSN = Trim$(Replace(aRRy(8), Chr$(34), vbNullString))
Doctype = UCase(Replace(aRRy(9), Chr$(34), vbNullString))
TIFfile = UCase(Replace(aRRy(7), Chr$(34), vbNullString))
BatchID = Trim$(Replace(aRRy(10), Chr$(34), vbNullString))

ListView.ListItems.Add , , SSN
ListView.ListItems.Item(ListView.ListItems.Count).SubItems(1) = Doctype
Debug.Print TIFfile

ListView.ListItems.Item(ListView.ListItems.Count).SubItems(2) = TIFfile
If Len(SSN) <> 9 Then
ListView.ListItems.Item(ListView.ListItems.Count).ForeColor = vbRed
Else
ListView.ListItems.Item(ListView.ListItems.Count).ForeColor = vbBlack
End If
If EXIST(TIFfile) Then
ListView.ListItems.Item(ListView.ListItems.Count).ListSubItems.Item(2).ForeColor = vbBlack
Else
ListView.ListItems.Item(ListView.ListItems.Count).ListSubItems.Item(2).ForeColor = vbRed
End If

End If
Loop
Close #fnum1

Further work - FW1 R65 on Dell 2950

So far this install is flaky as can be. The FW.SYS (Firewall kernel level driver) BSOD's the machine once a week and quits routing daily. We've upgraded to HFA2, we have the latest Dell drivers, and have all services off except for those required.

SmartDefense isn't the problem, that's been eliminated. The problem with the BSOD is always processing NDIS. Sometimes when routing stops, the fw ctl zdebug drop shows that inbound packet queue is full. This is getting ridiculous. I think R65 just isn't stable at this point in time. I have had open tickets for many weeks now.

Firewall-1

FW1 NGX R65 install onto Windows 2003R2 on a Dell 2950 with Broadcom NICs and an Intel E1000 add on NIC.

Thing's I have learned;

1) fw ctl zdebug drop will show drops not logged in the normal log viewer
2) They have previously had issues with Broadcom NICs, though R65 should have that fix. They recommend N1000 type cards from Intel.
3) Make sure your IP addresses are setup right.

4) Make sure Duplex is right. Double check.

5) NDISWAN must not be installed. That is your 0.0.0.0 in topology. Windows 2003 uses this for remote access and routing. FW1 isn't compatible with this.
a) Go into device manager and look at your Network adapters.
Select VIEW / SHOW HIDDEN DEVICES. Disable all the WAN MINIPORT items, including the VPN-1/Fireall miniport.
Disable the service Routing and Remote access. With the WAN MINIPORT items disabled, Routing and Remote access service will fail upon boot.
b) Go into the registry and go into HKLM\system\currentcontrolset\services\tcpip\parameters and make IPEnableRouter set to 1.
This will enable routing without the Routing and Remote access service. This is what FW1 wants. Reboot to get all these changes in place... You might also add to this registry location MaxUserPort and set it to 65534. Default in Windows 2003 is 5000 ports. So you can only have 5000 connections at a given moment. 65534 is the maximum possible, so set it to that in decimal. It's 0X0000FFFd in Hex. Google search this fact and you'll find it numerous places.

c) In this same place in the registry as b, go into Interfaces and for each interface configure DontAddDefaultGatewayDefault as a dword set to 0. This prevents the interface from ever having a 169.254.x.x address.


d) Instead of typing in every route table entry again, if you are moving firewalls, simply take the PersistentRoute portion of this registry and export it as a .reg and import it to your new firewall & then reboot. It's also a good idea to export this for backups every now and again.