W3SVC1 Log Files Growing with WebDAV-Miniredir entries

One of my clients had a server with a somewhat limited C: drive. The server would occasionally fill up with log files that were hundreds of MB in size under the W3SVC folder with the same entry over and over... some kind of web request from a particular Vista machine to my server hitting WebDAV. This one plagued me for a while, but I finally sat down and traced where the error was being generated from.

According to a few internet sources, apparently there is some kind of problem with Vista and WebDAV, or more importantly Web Folders. I won't go into the details as they do not matter really... what's important is that Vista machines attempting to access a server running IIS and WebDAV may generate endless amounts of these WebDAV-Miniredir entries in your IIS logs. Eliminating whatever application is making these web requests is the key to preventing the log bloat.

In my case, the machine had Quickbooks 2009 installed, and along with it some kind of unused quickbooks web connector. The connector was set to run on startup (even though it wasn't doing anything), and thus whenever the vista machine was on it was generating a few lines of logs per second. Removing the web connector from the startup folder fixed the problem.

Installing 32 Bit Printer Drivers on a 64 Bit Windows 2008 Server

So here is a really dumb situation I found a resolution to after an hour wasted scratching my head. When installing an older printer on a Windows 2008 64 bit server and attempting to add some x86 drivers so that 32 bit workstations can print to it, Windows displays an error and asks for the "Windows Media (x86)". No CD or DVD I had contained what it was looking for... it turns out the solution was to install the printer with just 64 bit drivers, connect to it from a 32 bit windows 2008 server, and install the 32 bit drivers when prompted. After that, go to the properties of the network printer, click additional drivers, and check off the x86 box. It will upload the drivers to the 64 bit server for you. Detailed instructions below:

I created a queue for a new printer, installed the 64bit drivers and sent a test page. All was fine, so I decided to add the 32bit drivers so that some XP workstations would be able to print to it.

Each time I ticked the box, it would come up saying “Please provide path to Windows Media (x86 processor)” asking me for the ntprint.inf files from the i386 folder of the Windows media CD. Being 64bit Windows 2008, it doesn’t have an i386 folder on the media.

If you are having this issue with Windows 2008 64bit and HP drivers, here is the fix that I used below.

1. Go to a 32bit Windows Vista or 32bit Windows 2008 system and log on a user with admin rights on the print server.

2. Download the 32bit drivers you require for your printer and extract them.

3. Click on Start – run then type \\printserver (replace “printserver” with the name of your print server) and then double click on the printer, and install it. When prompted for drivers, point them to folder where you downloaded the drivers.

4. After it installs on the 32bit system, go into the local printers, right click on the network printer you just installed and choose properties, sharing, additional drivers and tick the x86 box. Click OK and the x86 drivers will upload to the server.

Credit for this one goes to: http://www.shnake.com/blog/?p=228

Removing Permissions in Exchange 2007 = Adding DENY permissons

Sometimes the most intuitive GUI based actions have strong underlying consequences. In this case, I was at a site that had an IT user whose mailbox suddenly became inaccessible. No other admins could get into it either. I began down the path of assuming this mailbox was corrupted... I disabled the mailbox thus removing it from the users account, and just out of interest, tried reattaching it to a test domain users account... it worked! The user was able to see and use the mailbox, no problem. I reattached it to the original admin... it stopped working.

Long story short, come to find, another domain admin had decided it would be more secure to go in and remove the 'domain admins' full permission to each of the admins at the site. This would only allow each admin to see their own mailbox and not eachothers. The problem with this was that Exchange 2007 implicitly adds a DENY permission whenever you remove an ALLOW permission. In this case, they removed the domain admins allow permission, so exchange 2007 added a DENY permission to the admins mailbox... thus blocking out all admins including himself.

Here is the command I used to discover this erroneous permissions entry:

get-mailboxpermission "username" | where{$_.Deny} | where{!$_.IsInherited}

This retrieves all deny permissions that are not inherited from the parent (mailstore). Low and Behold, Domain admins was listed with deny full access.

You will also notice this behavior if you look at the output of the Exchange GUI when you remove permissions... note there will be two successful commands displayed in the confirmation dialog... one to remove the permission, and one to add the deny permission. Goofy, no?

This command will remove that deny permission:

Remove-MailboxPermission -identity 'CN=User Name,CN=Users,DC=domain,DC=local' -User 'DOMAIN\Domain Admins' -Deny -InheritanceType 'All' -AccessRights 'FullAccess'

Citrix and Adobe Updater

Tired of all your users getting that message that they are not able to run the Adobe Updater every time they log into Citrix or the Citrix Desktop? Or even worse... tired of users updating your Adobe all the time on your Citrix servers? Here is a handy registry entry that will press the murder button on that Adobe Updater:

REG ADD "HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\8.0\FeatureLockdown" /v bUpdater /d 0 /t REG_DWORD /f

Note the 8.0 in that string... change it to 9.0 or whatever version you are running (best bet is to browse the registry for the specific string you need first). Don't forget to do a "change user /install" before and "change user /execute" after just to make sure.

---Update---

It seems that in some cases, that may not even be enough to stop the Adobe Updater. The final nail in the coffin, so to speak, after performing the above is to go into the C:\documents and settings\all users\ directory and hunt down Adobe_updater.exe, then rename it to .old. That should put this problem in the ground for good.

Ghost Network Cards after a P2V migration

I have learned many invaluable things in the past few days about P2Ving live production systems... but none so important as the following little gem. It seems that with most systems, when you P2V them you end up with Ghost network cards for each of your original physical NICs... that is, they do not show up in the device manager, yet they still use the static IP addresses you had assigned, do funny things to network communication and name resolution, etc. Here is how to get rid of them:

1) Open a command prompt and type in "SET DEVMGR_SHOW_NONPRESENT_DEVICES=1". You will not get a confirmation back, it will just drop back to the prompt. Now, in the SAME CMD window, without closing it...

2) Type in "DEVMGMT.MSC" to open the device manager from the command prompt. This is critical, if you dont open it from the same CMD window you typed the first step in, it wont work.

3) In device manager, go to View > Show hidden devices

4) Expand nic cards and right click on each fadded network card to remove it.

I tried following similar instructions over and over, and it was not until I launched the DEVMGMT.MSC from the command prompt that I set that first variable in that it worked.

Once I removed the ghost nic cards, set my static IP back to what it was supposed to be (as VMware converter gives the new vNIC a DHCP address) then rebooted, all was well.

The Six Simple Steps to a working ASA

Working with a Cisco ASA series can be daunting up front, especially when trying to configure it from the command line... but when you distill out all the fancy frills and extra features, there are really only six core components that need to be configured for a working firewall. Here they are:

Step1: Configure the internal interface vlan
------------------------------------------------------
ASA5505(config)# interface Vlan 1
ASA5505(config-if)# nameif inside
ASA5505(config-if)# security-level 100
ASA5505(config-if)# ip address 192.168.1.1 255.255.255.0
ASA5505(config-if)# no shut

Step 2: Configure the external interface vlan (connected to Internet)
-------------------------------------------------------------------------------------
ASA5505(config)# interface Vlan 2
ASA5505(config-if)# nameif outside
ASA5505(config-if)# security-level 0
ASA5505(config-if)# ip address 200.200.200.1 255.255.255.0
ASA5505(config-if)# no shut

Step 3: Assign Ethernet 0/0 to Vlan 2
-------------------------------------------------
ASA5505(config)# interface Ethernet0/0
ASA5505(config-if)# switchport access vlan 2
ASA5505(config-if)# no shut

Step 4: Enable the rest interfaces with no shut
--------------------------------------------------
ASA5505(config)# interface Ethernet0/1
ASA5505(config-if)# no shut
Do the same for Ethernet0/1 to 0/7.

Step 5: Configure PAT on the outside interface
-----------------------------------------------------
ASA5505(config)# global (outside) 1 interface
ASA5505(config)# nat (inside) 1 0.0.0.0 0.0.0.0

Step 6: Configure default route towards the ISP (assume default gateway is 200.200.200.2)
-----------------------------------------------------------------------------
ASA5505(config)# route outside 0.0.0.0 0.0.0.0 200.200.200.2 1

Cisco Etherchannel Configuration

I never seriously thought I would be blogging on how to configure Cisco devices, much less the advanced portions of the Cisco devices... but work has a funny way of making you learn things you never thought you would.

The site I am configuring has a HP blade enclosure with two Cisco Switches serving up the blades' primary and secondary ethernet connections. Right now, those switches have a single physical ethernet connection back to the core switch of the network (that way if one switch in the enclosure fails, the other takes over). We want to increase the bandwidth available between that blade center and the core switch because we are planning on filling up that blade center.

In addition, we have added a new core cisco switch as a fail over switch for total hardware redundancy up to the firewall. These two switches need to talk to eachother to pass traffic in the event that one goes down.

Enter Etherchannel, which aggregates single network connections on switches into a single logical connection with the combined bandwidth of both.

This is the site I used for configuring my switches: http://jklogic.net/cisco-ios-to-catos-etherchannel-configuration/

It gives a good understanding of what the tasks are at hand, but there are a few additional steps required to really get it going, and after confirming with a Cisco representative, this is what I ended up with for configuration:

Of the Cisco IOS flavor (cisco 3560G specifically, running 12.2):

...
!
interface port-channel1
switchport trunk encapsulation dot1q
switchport mode trunk
!
...
!
interface GigabitEthernet0/47
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode on
!
...

And of the CatOS variety (specifically the Cisco 2948G-GE-TX) we get:

...
!
#port channel
set port channel 2/47-48 20 (note that the 20 is an ID and is optional)
!
...
!
set trunk 2/47 nonegotiate dot1q (extra stuff about vlans)
set trunk 2/48 nonegotiate dot1q (extra stuff about vlans)
set port channel 2/47-48 mode on
end

At this point, you can connect the physical cables and you should have a working etherchannel. It looks deceptively easy written down... but this took like 6 hours to work out on the phone with Cisco.

For connecting IOS to IOS, just do the first IOS part on both devices... for CatOS to CatOS... you get the point.