DNS for tld’s not working on SBS 2008 when using root hints

by

After one day, you may find your Windows 2008 DNS Server is unable to resolve names in some top level domains (TLD’s) like .co.uk, .cn, and .br when it is configured to use root hints. This may also be seen with other top level domains too. According to Microsoft, a network monitor trace should show that the DNS Server does not send any DNS traffic out to the internet. The Windows 2008 DNS server returns SERVFAIL to the client or when using nslookup. I have not used Network Monitor to verify this myself, but I am sure if you loaded it up and used this MS KB to set up a trace that you would be able to verify this symptom.
Workarounds include restarting the DNS server, clearing the DNS cache, setting maxcachettl to 2 days or greater, and using DNS Forwarders instead of root hints.

 

This currently occurs with default SBS 2008 installs that have been configured to use root hints for DNS lookup. I have recently noticed this behaviour myself with two different SBS 2008 installs.

 

If you want to use root hints, you can set the maxcachettl registry value on the Windows 2008 DNS Server as follows:
1. Start Registry Editor (Regedit.exe).
2. Locate the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
3. On the Edit menu, click New, click DWORD (32-bit) Value and then add the following value:
Value: MaxCacheTtl
Data Type: DWORD
Data value: 0x2A300 (172800 in decimal = 2 days)
4. Click OK.
5. Quit Registry Editor.
6. Restart the DNS server.

 

Another way to get around this issue is to use the following method (I personally prefer this way):

1. Open up DNS under Administrative tools from the SBS server’s start menu.
2. Right click on the server name and select Properties.

 

dns-console1

 

3. Go to the Forwarders tab and click on the “edit” button.
4. Enter the primary DNS address of your ISP (In this case mine was BT so I used 194.72.0.98) and click Ok.
5. The forwarders section will now attempt to automatically resolve the FQDN for that IP. (Note you can also probably enter your router’s IP address in the forwarders section which should then get your SBS to look to the router for DNS information).

 

dns-console-properties

 

6. Click Ok to close the properties window and then close your DNS console.

 

DNS lookups for the TLDs should now be working again. If not, stop and restart DNS or give the server a reboot.

Cannot save the attachment. Can’t create file in Outlook.

by

Had this problem on a PC today – Outlook was having trouble opening .MHT file attachments from a contact item. Any attempt to open any .MHT file would result in an error message stating “Cannot save the attachment xxxxxxxxx.mht. Can’t create the file. It then asked to open the folder / file in question and check security permissions. This could happen for any attachment type, but in my case it was .MHTs.

Anyway the quick solution I found is to browse to the “OutlookSecureTempFolder” and remove all files listed in that directory. Close and restart Outlook and everything should be working again. Credit to this page where I found the solution.

1. Open REGEDIT.EXE and go to Edit -> Find… In the Find dialog box type “OutlookSecureTempFolder” without the quotes and locate that registry key.

2. That key will contain the actual folder location, and will look like:

C:\Documents and Settings\%USER_NAME%\Local Settings\Temporary Internet Files\OLK#\ (where # is a random letter or number)

3. Copy the location of that folder.

4. Click on Start -> Run… and paste the folder location from step #4 then click OK.

5. Windows Explorer will open that folder. Please, delete all files present.

6. Restart Microsoft Outlook and you should be able to open your attachments.

A quick update to this – the error occurs when you have the same document saved in this folder 99 times. This seems to be the maximum limit of times you can have an attachement from Outlook saved into this “temp” folder. Each time you open a file with the same file name from Outlook a new copy is saved here. For example (filename.zip (1) filename.zip (2) etc.)

Symantec System Center 10.1 not pushing out license files or definition updates

by

Today I had the issue whereby System Center would not update license files (.slf) for client PCs for a group in the console.

I could add the .slf on the server directly, but could not add it for each client PC. I could also not send virus definition updates to each client either, as the licenses had expired.

Anyway, it turns out that the Windows Firewall in XP for each of the clients was blocking these from going through. To resolve, just remotely manage the PC in question from the Computer Management console (Right-click My Computer, select Manage). Then click Action – Connect to another Computer. Type in the PC name and click Ok.

Once connected, browse to the services section, find the Windows Firewall / ICS service and right-click it. Select Disable from the menu.

disable-firewall

Now that the Windows Firewall is disabled, use the Symantec System Center console to push out the new license file for that PC in question, or a series of PCs.

install-licensefile

Once done, you can right click the selection of PC’s and update the virus definitions.

Be sure to turn the firewalls back on if you happen to use Windows Firewall / Internet connection sharing.

Proftpd FTP server initialization problem using uBuntu

by

identify-ftp-process

I had been battling with this particular issue for a while on my virtual machine running uBuntu 8.04 Hardy Heron. Basically it was a straight through install of 8.04, after which I installed lampp for PHP, mySQL, and FTP services so that I could host a couple of websites on this virtual machine.

At first everything was running 100% I hadn’t changed the default FTP server configuration that appeared to be working out of the box from the base install. Then one day I decided I wanted to play around with some settings and ended up somehow removing my FTP server – not entirely though as something was continuing to hold port 21 up and not allow me to use any other FTP server that used port 21.

What I did was I configured proftpd which seems to have come along with my install of lampp (Also known as xampp). I configured my users, IP address and all other details, but I was still getting problems when trying to connect via FTP from another PC on the local network.

Trying to start proftpd from the command line sudo /etc/init.d/proftpd start would result in the service appearing to start, but it wouldn’t actually be running. I confirmed this by opening the gproftpd GUI from System – Administration – GPROFTPD. The status at the top right of the GUI would say “Deactivated”

A very helpful user on the ubuntu forums also showed me a useful debug command that helped me identify my problem.

From the terminal, type:

sudo proftpd -nd6

This apparently starts proftpd in debug level 6.

It gives you a bunch of diagnostic information, and on the last line I spotted my problem:

Failed binding to ::, port 21: Address already in use

So, something else was already using port 21. Obviously my old FTP server’s remnants somewhere. Now to figure out what was using it.

sudo netstat -anp --tcp --udp | grep LISTEN

From that command, I found a line with :21 in it (indicating port 21) and at the end of the line, I found the process name and process ID number. The process in my case was inetd.

Now I went to see what the inetd.conf file had in it in terms of configuration:

sudo nano /etc/inetd.conf

This loads the nano text editor and displays the contents of the file. I had :

ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd

I made a copy of this inetd.conf file as a backup, and then deleted that entire line, as that was obviously what was holding port 21. Ctrl-X exits the editor, and I chose to press “Y” to save changes.

Now I needed to kill and restart the inetd process. I used :

sudo killall -HUP inetd

This kills the process, and allows inetd to restart and reload the inetd.conf file.

I went back to my proftpd.conf file and ensured it was setup to use port 21 for FTP connections, then restarted the proftpd service with :

sudo /etc/init.d/proftpd stop
sudo /etc/init.d/proftpd start

Then finally I went back to my other PC, and retried the FTP connection using FileZilla FTP client, and finally got connected! I hope this helps anyone with similar issues, as I had to use multiple sources to try and figure out what was causing this and where.