When you attempt to start the Windows 7 firewall service you receive the following error

Windows could not start the Windows Firewall on Local Computer. For more information, review the system event log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 5.

If you look in the System Event Log, you will see event 7024 from the Service Control Manager

The Windows Firewall service terminated with service-specific error Access is denied..

Cause

This may be caused because the “NT Service\MpsSvc” account does not have adequate permissions on the following registry key

HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess

Solution

1. In Registry Editor, browse to the key HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess
2. Right click SharedAccess, and click Permissions.
3. Click Add.
4. In the “Enter the object names to select” field, type “NT SERVICE\mpssvc”. Then click Check Names. The name should change to MpsSvc
5. Click OK.
6. Select Full Control in the Allow column.
7. Click OK.

Applies To

Windows 7 (all versions) / Windows Vista (all versions)

You receive a message from the Action Center that the Windows Firewall is turned off. When you attempt to turn it on, you receive a message like this:

Windows Firewall can’t change some of your settings
Error code 0×80070424

If you go into Services, you will find that the Windows Firewall service is missing. Also, the following registry key will be missing as well:

HKLM\System\CurrentControlSet\Services\MpsSvc

Solution

To fix this issue, copy the missing registry key from a working Windows 7 computer. If you don’t have access to another computer, download this reg file to your desktop and double-click it to import the missing key into your registry.

Now reboot your computer and the Windows Firewall service should be started.

If the service still won’t start, you may have permission problems or you may have other missing services such as the Base Filtering Engine

Applies To

Windows 7 (all versions)

If you have relay access control properly configured, only authenticated users should be able to relay mail through your server. If you are still seeing messages being relayed, then it’s possible a user account has been compromised. This will allow you to see which users are relaying mail so you know which account has been compromised.

Solution

Set Transport Logging to Maximum. This way the SMTP service will log a 1708 Information event which tells you which user account authenticated and which login method they used. You can use the Event Viewer to view these event log entries, filter for event ID 1708 in the Application Log.

1.     Start Exchange System Manager.
2.     Expand Servers, right-click Your_ Server_Name, and then click Properties.
3.     Click the Diagnostics Logging tab, and then click MSExchangeTransport under Services.
4.     Under Categories, click the Authentication category.
5.     Under Logging Level, set the level to Maximum

Now the next time somebody tries to relay mail through your server, an event 1708 will be written to the Application log. The event will contain the username that was used to authenticate.

Applies To

Exchange Server 2003

Microsoft Office Professional Plus 2010 has encountered an error during setup

This can be very frustrating since there is no error code or anything in the message that gives you a clue what the problem is. Usually this indicates that there are fragments of a previous Microsoft Office installation left behind on your hard drive. There are a number of solutions so I’ll start with the easiest first.

1. Delete the rgstn.lck file in the Microsoft Help folder. The location of this folder depends on your operating system and the rgstn.lck file is normally hidden so follow the instructions in Microsoft Knowledge Base article 927153. (NOTE: Some users have reported that you need to delete the entire Microsoft Help folder instead of just the rgstn.lck file)
2. Make sure you completely uninstall all versions of Office. Even after you uninstall Office using the normal procedure, there may be remnants left behind. Microsoft provides manual removal instructions in KB article 928218. However the instructions are quite complicated so I recommend using the “Fix It” utility on the same page. This utility can take a long time to run so if it seems to hang on one particular step just be patient and let it finish.
3. Use a program like CCleaner to delete temporary files and invalid registry entries. This is a good housekeeping measure anyway but it’s especially good after uninstalling something to clean up leftover remnants.
4. Disable all anti-virus software and/or clean-boot the computer. They always say to disable anti-virus software when installing a new program. Most of the time it doesn’t matter but there are times when it actually makes a difference. Even better yet is to clean-boot the computer so that nothing is running except the essentials. I’ll be making an article on that very soon.

Following those steps should get you going but if you’re still having problems, I’ve heard some people recommend re-registering the Windows Installer and checking permissions on the %TEMP% folder and the C:\Windows\Installer folder to make sure you have full-control. To re-register the Windows Installer run the following commands:

msiexec /unregister
msiexec /register

I hope that helps!

1. You are sharing files between two Windows 7 computers on the same network.
2. You go into the Network and Sharing center and turn off password protected sharing.
3. You try to access the shared resource from another computer and it still prompts you for a username and password.

Here’s what I did to solve it. On the computer that hosts the shared resource:

1. Make sure the Guest account is not disabled
2. Make sure the Guest account does not have a password. To make sure of this, go into Local Users and Computer and reset the Guest account password. Give it a blank password.
3. Make sure the Guest account is not denied access from the network. To do this, go into Local Security Policy and drill down to Local Policies -> User Rights Assignment. Look for a policy called “Deny access to this computer from the network.” If the Guest account is listed there, delete it.

Problem #1: No 64-bit JET driver
As you may know, SBS 2008 is required to run as a 64-bit operating system. That means IIS is also 64-bit. Unfortunately, Microsoft does not provide a 64-bit Jet driver for accessing Access databases. ASP worked but as soon as I tried to open a connection object, I got this error:

500 – Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.

Tracking this error down was a bit tricky. I had to enable Failed Request Tracing. When I reviewed the trace log, I found this:

Error 800a0e7a
Provider cannot be found. It may not be properly installed.

The provider string I was trying to use was:

Provider=Microsoft.Jet.OLEDB.4.0

Solution:
Create a new Application Pool and set it to 32-bit mode

Set the Default Web Site to use the new application pool

Problem #2: Application Pool Crashes
When I tried accessing my site again, I received a different error message

503 Service Unavailable

I also noticed that the application pool had changed it’s state to “Stopped”. Not good. A quick look in the Windows Event Viewer revealed event 2280:

The Module DLL C:\Windows\system32\RpcProxy\RpcProxy.dll failed to load.

RpcProxy is a 64-bit DLL required for Exchange to work properly. For some reason, it was trying to load in my 32-bit application pool causing the pool to stop working.

Solution:
Edit the c:\windows\system32\inetsrv\config\applicationhost.config file. Search for the following line and add preCondition=”bitness64″

<add name=”PasswordExpiryModule” image=”C:\Windows\system32\RpcProxy\RpcProxy.dll” preCondition=”bitness64″ />

Problem #3
Compression module does not load because there is no 32-bit driver. This will cause you to receive the following error:

HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

If you look in the trace log, you will see something like this:

ModuleName StaticCompressionModule
Notification 16
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 19
ErrorCode 2147942526
ConfigExceptionInfo
Notification MAP_REQUEST_HANDLER
ErrorCode The specified module could not be found. (0x8007007e)

Solution:
The solution is to disable HTTP compression. Unfortunately you can’t disable compression on a site-by-site basis so you will have to disable it server-wide. Run this command on the server to disable HTTP compression:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']

Update (1/15/2011):
I discovered today that installing Exchange 2007 Service Pack 3 causes the 32-bit application pool to stop working again. That is because the update adds a new 64-bit only DLL (exppw.dll) to the application pool causing it to crash. The solution is the same as for the RpcProxy DLL we did earlier except you need to add preCondition=”bitness64″ in two places in the applicationhost.config file . The first place is in the <globalModules> section:

<add name=”exppw” image=”C:\Program Files\Microsoft\Exchange Server\ClientAccess\Owa\auth\exppw.dll” preCondition=”bitness64″ />

and the second place is in the <modules> section:

<add name=”exppw” preCondition=”bitness64″ />

Resources:
ASP & Jet Provider
http://forums.iis.net/t/1066385.aspx

500.19 Error When Enabling 32-bit Application Pool
http://forums.iis.net/t/1149768.aspx

The Module DLL C:\Windows\system32\RpcProxy\RpcProxy.dll failed to load
http://forums.iis.net/t/1154189.aspx

Using Classic ASP with Microsoft Access Databases on IIS 7.0 and IIS 7.5
http://learn.iis.net/page.aspx/563/using-classic-asp-with-microsoft-access-databases-on-iis-70-and-iis-75

Exchange Server 2007 SP3 kills our 32-bit compiled ASP web application
http://social.technet.microsoft.com/Forums/en-US/exchangesoftwareupdate/thread/c378f8b5-6ac5-4871-ba70-7eef7d5a1cf4

Unknown Hz value! (75) Assume 100

I decided to run rkhunter to check for rootkits. Needless to say, I was disappointed to discover that I had the SHV5 Rootkit on my machine. Let me tell you, it’s not a good feeling to know you’ve been hacked. Now I know common wisdom dictates that rootkit-infected machines be formatted and reloaded from scratch but that is not something you do without a lot of planning and preparation. The first thing I wanted to do was get this bad guy off my machine and try to minimize the damage.

How it works

I did some quick googling and I discovered this page which was very helpful. However, I wanted to add a few more details that might help somebody out in the future. Basically what I discovered is that the rootkit installs an SSH server as a backdoor for the hacker to obtain access to your machine. In my case it was running on port 6522 but this is configurable by the hacker so your mileage my vary.

The hacker does not need to know any passwords to login to your system because the rootkit installs a public key file. The hacker simply needs to have the corresponding private key to authenticate to your server. Unfortunately all of this was invisible to me because the rootkit modifies several core utilities such as ‘ls’ and ‘netstat’ to hide it’s presence. The modified versions of these utilities work just like the real ones, except they don’t display anything that might be incriminating such as certain files and folders, or tell-tale processes.

Cleaning it up

The first thing you have to do before you can start cleaning up a rootkit infection is to get your original system files back. Luckily, the rootkit makes this rather easy by setting the immutable bit on the modified files. The purpose is to prevent anyone from deleting or overwriting the hacked files but it also gives us an easy way to tell what’s been modified. After you run rkhunter, there should be a log file in /var/log called rkhunter.log. Search through this log file to see what files have the immutable bit set. These are the ones we need to replace. I’ll use /bin/ls in my examples.

First, unset the immutable flag by using this command:

chattr -sia /bin/ls

Then, you can optionally make a copy of the hacked file for future use. This is helpful to compare the output from the hacked version to the output of the real version to see what’s different.

mv /bin/ls /bin/ls.hacked

Next, figure out which RPM your file belongs to by running this:

rpm -qif /bin/ls

This will tell you the source RPM. To get the binary RPM just replace ‘.src.rpm’ with ‘.i386.rpm’. For example, on my machine, the source RPM for /bin/ls is:

coreutils-5.97-19.el5.src.rpm

So the file I needed to download was:

coreutils-5.97-19.el5.i386.rpm

You can Google the name of this file or look on popular RPM sites such as rpmfind.net or rpm.pbone.net. Once you are sure you have the correct file, install it using the –force command.

rpm -i –force coreutils-5.97-19.el5.i386.rpm

This tells the installer to try to reinstall the package even though it’s already installed and to replace files as necessary. If you get any errors about files that it can’t  replace, it’s probably because those files have the immutable bit set as well. Clear the immutable bit on those files and install the package again until there are no errors.

Repeat this whole process for every file in rkhunter.log that has the immutable bit set. You will probably have to download several different packages.

Now that you have reliable system commands you can begin ripping out the rootkit. Use netstat to see what ports are open and look for anything suspicious.

netstat -ln –programs

This is where it’s handy to have the output from the hacked version of netstat so you can compare. In my case, I found a program called ttyload that was listening on port 6522. I killed the process and deleted the file. After that I confirmed that my server was no longer accessible on that port. I also used the information in rkhunter.log to locate and delete a number of other files and folders as well. Here’s a list of some of the more interesting ones.

Make sure you check your /etc/inittab and all the files in /etc/rc.d to see if the rootkit is loading anything at startup. In my case I had to remove the line that calls /usr/sbin/ttyload from /etc/inittab.

Final thoughts

Here are some final thoughts on what to do next.

1. Change the root password and the passwords for any other privileged accounts you may have.
2. Reboot the server and make sure things are still normal after the system comes back up.
3. Use iptables to block incoming connections on all ports other than the ones you need.
4. Strongly consider a full format and reload of your system.
5. Run rkhunter on a regular basis

#!/bin/sh
USERNAME=admin
PASSWORD=topsecret
BACKUPDIR=/var/local/mysql-backups

for i in $(mysql -u $USERNAME -p$PASSWORD -e "SHOW DATABASES;" --skip-column-names --batch)
do
   echo "Backing up database $i"
   mysqldump -u $USERNAME -p$PASSWORD --opt $i | gzip > $BACKUPDIR/$i.sql.gz
done

Of course, you will need to edit the first two lines to reflect your own username and password. When you run this script, it will create a bunch of files in the /var/local/mysql-backups directory, one for each database. The files are compressed to save space.  Of course, you’ll need to make sure the destination directory exists.

Personal Antivirus sounds like a wonderful program that might be good to have, right? Actually, it’s just one of an increasingly common type of malware called a rogue anti-virus or rogue anti-spyware program. It appears to be harmless or even beneficial on the surface, but it’s actual goal is to scare you into thinking you have some nasty virus that can only be removed by purchasing their removal software. It’s sort of like digital blackmail. Similar “products” include XP Antivirus, Antivirus 2008/2009 , Antivirus 360, etc…

How do I get rid of it?

Unlike most legitimate programs, there is no automatic un-installation method. That’s because the people behind these scams don’t want you to remove their software. They usually don’t show up in the list of programs in the Add/Remove Programs control panel applet. However, in many cases, manual removal is simple. Here are the steps I use. Keep in mind there are many different variants of this program so your mileage may vary.

Step 1: Terminate the application

Open Task Manager and look for a process called “pav.exe”. Highlight this process and click End Task. Once the process has been ended, the tray icon and application window should disappear.

Step 2: Prevent the program from starting up

Download a program called HijackThis. After you’ve installed it, run HijackThis and do a system scan. Look for any reference to the file pav.exe. Usually there will be at least one reference on a line that starts with “Run”. Put a check beside any that you find and click “Fix”

Step 3: Delete the program files

Delete the Personal Antivirus folder located in C:\Program Files.  You should also delete the shortcut on the desktop and the Personal Antivirus folder in the start menu.

That’s it. Reboot your computer just to make sure it doesn’t come back at startup. One optional step is to run a registry cleaner like CCleaner after you’re done. That should remove any leftover registry keys that reference the missing program file folder.

So do I really have a virus?

Just because Personal Antivirus was on your system and it said you have a virus, that does not mean you’re actually infected. However, I strongly recommend doing a full system scan with a legitimate anti-virus program and an anti-spyware program just to be safe. If you don’t already have one, here’s a list of some free alternatives.

Free Anti-Virus software (install only one at a time)
AVG
Avast
Avira AntiVir

Free Anti-Spyware software
Spybot Search & Destroy
AdAware