Category — Windows

The Windows Event viewer can sometimes seem like a blessing and a curse. Sometimes the messages can really help you discover what might be going wrong with the operating system or an application. Then Microsoft began to include hyperlinks that would help us get more information on what the error message was trying to tell us. But most times when you clicked on that hyperlink, all that you get is something to the effect of "Sorry. We don’t know what it means either."

So, I have had my share of disappointments with messages from the event viewer.

However, recently, I got an error message in the event viewer that not only told me what had gone wrong (and in language that I could understand), the message actually told me how to fix the problem. And I did not have to go out to a web page either!

The problem that I had been trying to fix was that some computers on my network were not getting the Group Policy firewall settings that I had recently changed. Some computers were getting the settings, but others, even when using a forced GPUPDATE would still not update the firewall setting.

After weeks of searching, I found myself in the place I should have gone to in the beginning - the Windows Event Viewer of one of my Domain Controllers.

In the File Replication Service event viewer there was an error message related to replication of data between my two Domain Controllers. This would explain my situation. Since the two  domain controllers were out of sync, this domain controller had the older firewall settings. Some of my computers were getting their updates using the older settings from this domain controller.

Now normally I would then have to search the Microsoft Knowledge Base to figure out how to solve this. But read the details of this error message (isn’t it pure poetry?)

Event Type:    Error
Event Source:    NtFrs
Event Category:    None
Event ID:    13568
Date:        9/12/2008
Time:        3:13:07 AM
User:        N/A
Computer:    Domain Controller
Description:
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is   : "c:\windows\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons.
[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
 Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.
WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.
To change this registry parameter, run regedit.
Click on Start, Run and type regedit.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
   "System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
   "Enable Journal Wrap Automatic Restore"
and update the value.
If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

It’s just amazing! The solution is in the error message details!

After I performed the steps outlined in the error message, all of my clients now have the proper firewall settings.

This is error documentation at its best!

So, my recommendation from this experience is this. If you are having a problem with Group Policy settings not being applied to all of your clients, check the File Replication Service Event log on all of your domain controllers for any error messages.  Who knows, it may give you the solution to your problems.

Recently I was just trying to run XAMPP Lite on my Vista PC.  XAMPP is a cool little utility that lets you run Apache, MySQL, PHP, and Perl all from a USB drive and without installing anything to your windows computer. Although I could get MySQL to start, I could not get Apache to start up. I did not have IIS installed, which could have caused a conflict with Apache, since both are web servers.

I ran xampp-portcheck, the port check utility that was included with XAMPP. It showed that ports 80 and 443 were being used by SYSTEM (see below).

RESULT
——

Service              Port   Status
==================================
Apache (HTTP)          80   SYSTEM
Apache (WebDAV)        81   free
Apache (HTTPS)        443   SYSTEM

MySQL                3306   free

FileZilla (FTP)        21   free
FileZilla (Admin)   14147   free

Mercury (SMTP)         25   free
Mercury (POP3)        110   free
Mercury (IMAP)        143   free

I opened a browser and it reacted as if I had a web server on localhost. The page was blank.

I decided to view the HTML source code and found the following:

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<HTML><HEAD>
<META http-equiv=Content-Type content=”text/html; charset=windows-1252″></HEAD>
<BODY></BODY>
<META content=FUGCLQURCL name=SKYPE_FRAMEID>
<META content=FUGCLQURCL name=SKYPE_FRAMEID></HTML>

I noticed that at the bottom of the source code in a META tag, there was a value of SKYPE_FRAMEID. I decided to stop Skype and sure enough Apache was able to start.

I then started Skype and both programs are able to run.

Skype is a smart program. Since most firewalls allow ports 80 and 443 for web traffic, Skype uses those ports if they are available. If 80 and 443 are in use, Skype will choose other ports to use.

This mysterious message was well documented by Microsoft.

Everyone knows that any user in a domain, even down to the user with least privileges, is able to connect to a network shared printer, right?

That is what I thought, until one of my users tried to connect to a shared printer and got the following error message:

Other users on my network can connect to shared printers with no problems. I did not remember creating a group policy to cause this. What is going on?

I found a Microsoft Knowledge base article (888046) with the answer. The first cause mentioned is trying to install a third party driver. Although the driver is from HP, I have never had this problem before with HP. The second cause had to do with the DNS setup. In my case, for this subnet, I did not have the DNS reverse lookup zone configured properly. To fix the problem quickly, I gave the user administrative permissions to the local computer and he was able to connect to the shared printer. I also created a reverse lookup zone for this subnet to solve what I believe was the main cause of my problem.

From time to time, I would like to highlight mysterious error messages that I have received and the solutions that fixed it.

I have a trust with another domain. A developer, with a user id in my domain, asked for access to a share on the web server in the other domain. I went to the web server and I added the developers group (which was a global group in my domain) to the share and the NTFS permissions.

The developer, with the proper share and NTFS permissions, should have access to the server, right?

I thought so. But the developer called me and told me that he could not connect. I added my non-admin user id to the developers group. I couldn’t get in either.

So, to the command prompt I go. I typed in a net use command to connect to the share. BREAKTHROUGH! An error message is returned. It read as follows:

Logon Failure:  The user has not been granted the requested logon type at this computer.

Doing a little research, I discovered that the error had to do with the user rights. Even though I had a valid trust relationship, valid share permissions, and valid NTFS permissions, the developer still lacked the user right to "Access this computer from the network."

To fix this problem:

1. Go to Start-Administrative Tools-Local Security Policy

   

2. Under Security Setttings, expand Local Policies and click on User Rights Assignment.
3. On the right side, modify the Access this computer from the network policy by double-clicking on it.
   
4. Click on the Add User or Group button to add the user or group to the policy. Click OK to save.

Ok, folks. This is a weird one I encountered.

I recently migrated a client of mine from a computer running Windows XP/Office 2003 to a new computer running Windows Vista/Office 2007. I used the Windows Vista utility, Windows Easy Transfer to migrate the settings from the old XP computer to the new Vista computer. You do NOT want to use the File and Settings Transfer Wizard that comes with XP, as it will only transfer files and not settings.

Windows Easy Transfer worked like a charm. It transferred all of my user’s settings and files. I then installed Outlook 2007. I opened Outlook 2007 for the first time and I was pleasantly surprised to find out that Windows Easy Transfer has transferred the Outlook settings. All of the user folders and archives were there. Outlook then went out and successfully downloaded new email. I was amazed at how easy this migration went. Outlook 2007 seemed to be fully functional.

Then came the phone call the next day. Although she was receiving emails (which is what I had checked), my client could not SEND any emails! (which I did not think to check!) When trying to send emails, the following error would occur: “None of the authentication methods supported by this client are supported by your server” I searched the Internet only to find very spotty coverage of this problem. What I did find was odd.

It had to do with authenticating before sending an email. In Outlook 2003, the user account did not need to authenticate to the mail server before sending. So that was the setting transferred to Outlook 2007. You would assume that the same settings that worked in Outlook 2003 would work in Outlook 2007 with the same email account and the same email provider, right? Not in this case (and evidently a few others on the Internet). I have also found variations of this problem on the Internet where the authentication had to be turned OFF in Outlook 2007 when it was ON in Outlook 2003.

Here are the steps to follow:

1. In the Outlook menu, go to TOOLS-ACCOUNT SETTINGS
2. Select the mail Account. Click on Change

3. Choose the More Settings button.

4. On the Outgoing Server tab, check the box for My Outgoing Server (SMTP) requires authentication. Also, select the Log on to incoming main server before sending mail button. Click OK