I was getting calls from one account running Exchange 2003 that at random times that they could not send email to one domain. I looked at logs and I see nothing helpful. My account found ways around the issue, maybe faxing or alternate email accounts. One day I found this article by Michael which solved that account’s problem. At least I have not heard anyone complain in a while. The deadly greylisting where the mail server does not answer a sending email server’s command immediately. The idea is to prevent spammers from doing their evil. http://theessentialexchange.com/blogs/michael/archive/2007/11/16/exchange-2003-sp2-and-greylisting.aspx glitchretry is what I modified. http://technet.microsoft.com/en-us/library/aa998772(EXCHG.65).aspx
I got a call from another account running Exchange 2007 that they cannot send and the guy who administers the recipient server says the server is perfect. So I open up Microsoft’s article on telnet to Exchange. http://support.microsoft.com/kb/153119
I type the commands and the rcpt to:email@example.com does not respond. I bang the enter key again and look off. I get an invalid command when I get back to looking at my telnet screen. I start over with the telnet stuff but this time I use the other enter key. It takes 2 minutes to get a response to rcpt to”firstname.lastname@example.org. Well that refreshes my mind so I am off to find Michael’s article which I did not bookmark. I then searched for glitchretry Exchange 2007 and got this article. http://technet.microsoft.com/en-us/library/aa998043(EXCHG.80).aspx
Hopefully this gets things working. Talking with my account contact she says that a lot of folks at different organizations are complaining that they cannot send to the trouble company. I suspect some Exchange administrator was being clever doing greylisting but did not tell his valid senders how to fix what he “broke.”
Do not trust my copy and paste. It goofed up but here is the section I was working with.
Configuring the Queue Glitch Retry Interval
The queue glitch retry interval specifies the interval between each connection attempt that is specified by the QueueGlitchRetryCount parameter. The default queue glitch retry interval is 1 minute. Typically, you don’t have to modify this parameter unless the network is unreliable and continues to experience many accidentally dropped connections.
To modify the queue glitch retry interval
Open the following file by using Notepad: C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config.
Modify the following line in the
<add key=”QueueGlitchRetryInterval” value=”<hh:mm:ss>” />
For example, to change the queue glitch retry count to 30 seconds, modify the QueueGlitchRetryCount parameter as follows:
<add key=”QueueGlitchRetryInterval” value=”00:00:30″ />
Save and close the EdgeTransport.exe.config file.
Restart the Microsoft Exchange Transport service.
To specify an age value, enter the value as a time span, as follows: hh:mm:ss, where h = hours, m = minutes, and s = seconds.
So that stuff did not really help. I looked at the Exchange logs. Specifically I went in to Exchange Management Console and under Server Configuration/Hub Transport at the top right box I right clicked on my server name and properties. In log settings I checked Enable Connectivity logging noting where the log is. A bunch of oks and I restarted the Microsoft Exchange Transport. I looked at the log and the problem domain was showing dns errors.
I did an ipconfig/flushdns which did nothing. I looked up the domain using www.mxtoolbox.com I pinged the server listed. Quick solution was I added www.opendns.com server numbers of 22.214.171.124 and 126.96.36.199 in the DNS management console. right click server name and properties. There is some issue with edns probes that I need to figure out but I need to get some hardware delivered to an account. Oh, setting the server to use opendns servers got that mail flowing.
Application server was replaced. We had an OKI B4600 and a Dymo Labelwriter 400 attached to cheap print sharing devices. They worked fine for years. They did not work after new server. I goofed around for a lot of hours one day and Quest support was no help. They supplied the printers but not the print sharing devices. Dymo worked fine when attached to server directly via USB cable but not through usb print server. I did not try to carry the OKI ovver but it printed fine from laptop directly attached to usb cable. It happened to be a parallel print sharing device though. Another day of messing with this stuff. Two new print servers did not help. I went back to the old devices with no luck. Google like crazy wasting time. Stumble on some comment about unchecking SNMP in tcp port properties. Viola, it worked.
I am excited to head to New Orleans tomorrow for Jeff Middleton’s IT conference. I have never been to an IT conference, just some Microsoft stuff. It should be fun as I have already met 20+ of the people who will be attending. I am looking forward to meeting names I have read about.
I got a call about a HP LJ2035n. The user could not see the printer using the wizard. Is the network connection on the printer lit up? No. Read the wall jack and go plug it in on the switch. Drama comments so I go to visit. Actually that is not a bad thing as the cabling infrastructure is a mess due to a remodeling project a few years ago that was done out of sequence. I get the printer plugged in and the wizard sees the printer but cannot administer it. Power cycle the printer does not help. That account does not have a dhcp server which does not help. Since the wizard on the CD did not work I thought I would try WebJetAdmin. I was having a temper tantrum as the WebJetadmin required .net 3.5 which I downloaded and installed. That little setup can take forever starting with a search for a good redistributable. Then it complained about a version of Windows Installer. So off I went to the Dell printer to chill. I took a workgroup switch out of the Dell printer office as we did usb this time. Her HP 4000n was giving up the ghost. Back to the 2035n. I called HP with a printer configuration page on hand. They quickly had me doing a route add to that 169 automatic private IP address(APIPA). You have probably seen that ip before when something that is supposed to see a dhcp server but it doesn’t. So it creates an ip of 169.x.x.x. I could ping once maybe and the next few replies went dead. I grabbed the just removed workgroup switch. I attached the printer and the workstation to that same baby workgroup switch and now I had good pings. I then was able to finish the wizard and assign the printer a valid ip.
I have been bit by this a few times in the past but I think I used to have an old Jetadmin cd that seemed to work ok. Or maybe it was a different switch that was not wacking or blocking the pings and communication. So one of two tools would be handy. A 5 port workgroup switch or a crossover cable. Of course a route add statement so the workstation knows how to get to a APIPA is a critical part of the adventure.
I don’t remember if I told this story. An account I have works on the hospital portal. They click on something and a Citrix session starts up. Click deep enough and it pops up an extranet Internet Explorer session that is supposed to set up some proxy settings. I beat my head against the wall trying to get it to work. The hospital spent time trying to fix it. I finally compose a long note to my friends to see if they had any ideas. 3 long paragraphs later I tried to do a summary flow chart. Once I did the summary flow chart I discovered how Citrix was in the mix. I went back and uninstalled the ICA client. Rebooted and deleted any Citrix I could see in the registry and on the hard drive. I started up the hospital portal. Installed the ICA client and started clicking to the problem website. Things went slow as the various clicks sent whatever programs the ICA wanted to send to the workstation. Everything worked. Things worked faster the next time as the workstation now had programs and settings in its cache. I guess if I knew how to delete that ICA cache it would have had the same affect, maybe. Not knowing my way around Citrix I just guess.
My take away on this troubleshooting was listing the steps I knew and filling in the blanks. Sometimes writing stuff down and flow charting forces problems and solutions to bubble up.
I got a call about a workstation with a dead nic. In device manager it shows up with an exclamation mark. Vista 64 bit box. I tried to install the drivers from the Intel CD which did not help. I tried the drivers from the Intel web site which did not help. An Intel salesman calls me while I am doing this. I fuss that I am working on a DG33. He says what is that. A salesman that does not know his products. That motherboard has not been deprecated that long ago. In any event he got me a support engineer saving me partner id and all that stuff. We tried the driver again. Updated the bios. Still no joy. I shut down the workstation. Unplugged the power and the nic cable. Pressed the power button to drain the energy from the motherboard. Power up and in the bios we disabled the nic and booted into Vista. Back down and then we got back to the bios and turned the nic back on. Vista found the nic and all was good. The engineer said you have to unplug everything and remove the cmos battery for a half hour that motherboard discharge trick to work. I suppose some capacitors can hang on to some energy. I did not feel like arguing on that point. At least a half dozen times that power and nic cable unplug and power button press has successfully reset a stuck nic. First time I have had to disable in the bios but it sounds like a good trick to remember.
I delivered a new SBS 2003 to replace an old SBS 2003. We had some goofed up Active Directory stuff so the thought was we would just start from scratch but pick up the old Exchange database and place it on the new server. That worked fine but we had some issues with speed of backup. The lab backup and remount worked fine but it took many hours to copy the Exchange database. Anyway there was a bit of overlap that for some reason I did an Exmerge from old server to catch 2 days of email. I really do not recall what happened but anyways. Workstations unjoined and joined to new server. Exmerged everyone back in which worked for all but one. Did an Outlook merge which looked ok. On Monday that problem user reported that he was not getting new mail but everyone else was. Seems odd but yes indeed there sat for local delivery were all of his messages. I did an export of his messages from Outlook to a pst. Deleted his mailbox. Purged the mailbox after editing the retention time. Created new mailbox. Mail was still stuck in queue. Google to the rescue. http://www.thecyberwolfe.com/blog/?p=665 I did the regedit mentioned. Mail flowed. All was good. Google is great if you can imagine the correct search words. Plenty of times I do not find what I need. I am surely not a pioneer but I guess some folks never publicly document their victories over IT frustration.
I can’t backup.Something about media or it starts a backup and bombs along the way.
I start with the basics. We currently use usb drives to back up for the most part. Can you see the usb drive from My Computer? Yes is good. No means you need to power down the usb drive, check the connections on the usb cable and power it back up. If it still does not appear try plugging it in to your laptop.
Yes you see it. How much free space does it have? How many backups is the server supposed to save to the drive? 6 copies of a 60 gig backup is going to cause problems on a 300 gig drive. Adjust the number of backups saved, get a bigger usb drive or maybe some file cleanup on the server.
File cleanup on the server:
Search for old *.dmp files. Not a lot of point saving them once you figured out why the server is dumping.
Clear out old logs in the System32 folder.
Review your music policy. When you do My Documents redirect to the server you can send a lot of music and pictures to the server that have nothing to do with work.
Encourage users to clean out their workstation Recycle bin. I use Treesize from Jamsoft. I see gigs of crud on the server because people delete stuff but they do not empty their recycle bin. Treesize is a great utility to help find wasted storage.
Search user folders for old *.tmp, *.dmp and ~*.* files. They all waste space if they are not currently in use.
Backing up to a NAS? When you ran the backup wizard did you choose to back up to \\192.168.16.9\share or did you choose \\simpleshare\share ? Well you just introduced a dns issue. The server may sometimes know what you mean by \\simpleshare but do not bet on it. Since you set the NAS at a static ip, add a host entry in DNS on the server for that ip and name. Start\Administrative Tools\Dns. Your domain name\Forward Lookup Zones\your internal domain name. Right click on the right side and add a new host.
Backing up to a NAS makes backing up to a USB drive seem fast. About 10 gigs an hour for the Simpleshare.I am told that E-SATA is pretty fast but I have not tried it.
I can’t print. Tales of tcpip printing.
I have recently had calls about I cannot print. The first was a peer to peer I cannot print. I visit and I cannot ping the printer based on the printer tcpip port properties. Is the printer plugged in to the network? Yes for one and no for another. What is the ip? How is the printer getting its ip? What is doing dhcp? So the first account had a router serving up ips starting at 1. They had about 10 workstations. Printer was hanging out at .5 with a static ip. Ip conflict with a workstation. I moved the printer up to .105 and all was good. Workstation that had that ip started working better. Next printer was an old Xerox which prints great when and if it can print. Once it was plugged in to the network and had a non-conflicting ip all should be good. I could open up the web interface. I actually got it to print out some pages.
I got a call about the troublesome old Xerox printer. I had spent a few hours trying to get it to behave last time I was there. For $150 you can get a brand new Brother network printer which for a low volume workgroup works fine. I had given up on that Xerox which was long discontinued with I assume no support. I had no luck with any driver I used. Well I had a bit of luck as it spit out a few pages but not consistently or with any useful words on the pages.
Next account. I can print sometimes but often not. What is the ip? I can ping but I cannot get to the web interface. Printer has a static ip. Who picked that ip? It certainly was not me. What is doing dhcp? I look at the dhcp table on the server and I see that ip is listed for remote access vpn use. So there is the conflict. We set the printer to a new ip up in the 200’s, at a tcpip printer port and printing is solved.
Next account. Another domain but this office has a bunch of satellite offices with workstations that are not domain members. It is an icky network but my hands are tied. 4 laptops can print to their local tcpip printer and they can print when they remote desktop to the application server. I start at the first laptop. It can print from notepad but that printer never shows up when I log on to the application server. Even when I am logged on as a local administrator and as a domain administrator. I disabled anti-virus. I tried moving from wireless to wired. I check that the remote desktop has printer redirected. I check the settings on another laptop and its remote desktop client looks slightly different. I install the rdp6.1 client from my usb thumb drive. Log in and now the printer is properly redirecting.
I go to the next laptop and install rdp6.1. Then I look at the local printer. There is no local printer. I could swear I had all the laptops set up with a local tcpip printer. Added a printer and all was well.
The other gotcha of course is that your application server has to have the correct driver installed for your local remote printer. On the application server you open up printers and faxes. Click on the word File and Server Properties. Choose the drivers tab and add drivers. If you do not have an exact match you will never print. If you review your event viewer logs you should see a message about printer not added for the remote session. That also gives you a good clue about what driver you need to dig up. This also works if you are trying to remote in to your XP workstation and you cannot print.
I like to set up my dhcp servers with an exclusion range that I use for printers. This reduces the chances of ip conflicts. If the customers would just call me when their printer company visits all would be good. I also like to turn off some of the informational logging in server properties so when I have an issue I can find it. With 20+ users on an application server you can have plenty of print logs of which most are useless for troubleshooting problems.
I got a call that two workstations at check in were off the network. I suggested running Malwarebytes Antimalware. That has fixed a few machines at that account. Note that I just got this account. It has almost 100 devices at two locations, no domain, no centralized anti-virus console, no dhcp, four servers, a Sonicwall, A Cisco Pix, no network documentation. And they are about 1.5 hours from the house in good traffic. Wah. So the local guy ran the anti-malware program which came out clean. He changed out the workgroup switch which did not help. They were attached to a workgroup switch that was attached to a HP Procurve switch. I have found that HP Procurve switches are just about bulletproof. I delay a server install to do what I hoped was a quick look see.
I do my usual delete temp internet files, click box in IE to delete temp IE files when exiting and I delete temp files from user profile. I updated nic drivers. I ran WinsockXPfix which did nothing. I assume that it might do something but they were Windows 2000 boxes. Nothing I could do would get the workstation or my laptop to see the network. I plugged the network cable in directly to a workstation bypassing the workgroup switch and got nothing. I walked back to the HP Procurve switch with my laptop and still get nothing. My $100 cable tester shows 4 blinky lights the whole way so network cable and patch cords are probably ok. I try another port on the Procurve and all was good. The network switch got a stuck port but I was not going to reboot the switch that had 72 devices plugged in to it, especially during working hours. I do not recall ever having a Procurve port get stuck or fail. Plenty of failures on other switches though. Usually a reboot of the switch will fix it but I have had some switches keep failing and a replacement solves that problem.
Back to the check in counter. My laptop works there with the workgroup switch. One of the workstations that was down was now up. The workstation I did the most experimenting with was still down. When I used the same static ip my laptop worked so it was not an ip conflict. I gave up on that troubled workstation and reported back to the company manager. They are on a slow workstation replacement getting rid of these old W2K boxes. As I went back to gather up my laptop and tools I had one last ditch effort. I disabled the workstation nic and re-enabled it. It started working. Man was I in hot water. Those ladies so much wanted to get rid of those old slow W2K boxes.