So you’ve got a Microsoft Access database with linked tables to a SQL server that looks something like this.
When opening one of the linked table you get an error that says, “ODBC–connection to ‘DP’ failed”.
When you click OK you get a message that says, “Microsoft Access can’t open the table in Datasheet view”.
Hmm, what up with the ODBC connection called “DP”? What say you Procmon?
Result = NAME NOT FOUND. Oh, the ODBC connection doesn’t exist. Create the ODBC connection & you are good to go.
I admit that you could have also just gone & looked at the ODBC connections in the Control Panel to figure out it doesn’t exist but it was really just an excuse to use Procmon.
From my home network I signed up to watch a webinar. As is typical when registering for a webinar I was provided the option to download an ICS file to save to my Outlook calendar. I clicked the link to open the ICS file & Outlook 2010 (which was already open) hung for about 3 minutes then finally displayed the appointment.
I closed the calendar item then clicked the link again only this time I saved it to my desktop. I double clicked the ICS file & same thing. Outlook hung for about 3 minutes.
I run Process Monitor & open the ICS file again to get a capture. After the appointment opens I stop the capture. I set the filter to only show Outlook.exe. In a case like this where I’m not really sure what’s going on I go through each of the utilities on the Tools menu. Nothing is really jumping out at me until I open Network Summary.
What’s with Outlook connecting to these various IPs? I flip over to Process Explorer, open the Properties of the running Outlook process, & select the TCP/IP tab. I open the ICS file again. To my surprise I see Outlook making all these connections for the next few minutes.
Well this should not be happening. My Outlook profile is configured to connect to a CAS array which does not have a public DNS record. I run a DIG to see what’s getting resolved. (I’m using alternate info but the results are the same with my production FQDN.)
Yeah, that’s not right. I should be getting a status of NXDOMAIN & no answers.
So what’s going on? DNS Hijacking or as Cox Communications likes to call it…”Enhanced Error Results”. I’ll post some links below for further reading but in a nutshell, DNS hijacking means that when you browse to a website (i.e. query DNS for an FQDN) that does not exist the DNS server returns an IP address instead of an NXDOMAIN error. Since you received an IP address your browser will go to that site. A chill should have just gone down your spine.
In my case Cox was gracious enough to post an article on how to “opt-out of enhanced error results”. I have to hard code two alternate DNS servers in my router. Once I made the change & renewed my IP settings I did another DIG.
Much better. I open the ICS file & it pops right up. “Problem” solved I guess. Of course I wish Outlook would handle this a little better. I have been unable to find a KB article addressing this issue but if you know of one please leave a comment. One day when I have some spare time I might open up a case with Microsoft about it.
Links & what not:
Now before any DNS hijacking huggers out there say anything I’m well aware of this draft RFC but it’s expired therefore RFC 1035 & 2308 take precedence. Even ICANN thinks it’s a bad idea. See here & here.
You can also read up on the subject here.
If you have to go back to using an older version of ProcMon the text may become small & difficult to read.
This was driving me crazy for a few minutes but was really easy to fix. Click Options>Font. The font size was set to 6.
Change font size to 8 & all is legible again.
I recently installed version 10.1.0 of Adobe Reader X on my Terminal Servers. The next day I start getting reports from users that they are unable to open some PDF files. They get an error that says, “Before proceeding you must first launch Adobe Acrobat and accept the End User License Agreement.”
Strange seeing as how the Terminal Servers don’t have Adobe Acrobat. I hop on the same server as one of the users & can open several PDFs just fine. I have them send me the file they are having trouble with & sure enough I get the same error. I log back in using a Domain Admin account & once again get the error.
So as Mark Russinovich always says…when in doubt, run Process Monitor. I run ProcMon & capture the error. The first thing I always search for is “Denied”. None are in the capture. To make it a little easier to analyze I filter to include only the AcroRd32.exe process. Then to clean it up a little more I exclude all “SUCCESS” results.
Now that the number of events is a little more manageable. I scroll through them & notice one that says HKLM\SOFTWARE\Adobe\Adobe
Acrobat\10.0\AdobeViewer\EULAAcceptedForBrowser NAME NOT FOUND. Hmmm…interesting.
I open Regedit & browse to HKLM\SOFTWARE\Adobe. Since it doesn’t exist I create the “Adobe Acrobat\10.0\AdobeViewer” key structure. Then I create a DWORD called “EULAAcceptedForBrowser” & set the Value Data to 1. I try the file again & it opens right up.
If you prefer, use the link below to download the fix in a reg file.
32bit version – https://www.box.com/s/fc81f4cfb55740fb723c
64bit version – https://www.box.com/s/5bc9cd5e536e498df533
<sarcasm>Nice work Adobe. Great product.</sarcasm>
UPDATE: In searching around a little more I came across this post on an Adobe Forum. Apparently if a PDF file has CR (that’s capital C capital R) anywhere in the filename (e.g. 123CR456.pdf or just CR.pdf) it will cause the EULA error to pop up. I went back & can confirm that all the PDF files that my users reported issues with all had CR somewhere in the filename. Nice find to GiaKzter for noticing the filename connection. That would explain why it is only for some files.
UPDATE: Thanks to Loren Amelang. The CR issue is related to the entire path not just the filename. See her comment below for an example. Thank you Adobe, can I have another. Thank you Adobe, can I have another…
I had a user report that every time she opened any spreadsheet in Excel 2000 when logged in to the Terminal Server it said “Simulation Template – filename.xls” instead of “Microsoft Excel – filename.xls“. Even if she just opened the Excel program first it still said “Simulation Template – Book 1”. It didn’t seem to affect anything negatively but it was still strange that it was showing up like this.
My first thought was she had saved a file in her XLStart folder (C:\Documents and Settings\username\Application Data\Microsoft\Excel\XLSTART) but there was nothing in there. Maybe somehow someone saved a file to the system XLStart folder (C:\Program Files\Microsoft Office\Office\XLStart). Nope, nothing there either.
OK, maybe there’s something in her user profile that’s messed up. I had her log off the Terminal Server. I verified that her profile had been deleted from the server & then rename her roaming profile & redirected folders so that when she logged in it created everything from scratch. When she logged back in everything appeared as expected as if she was logging in for the first time. When she launched Excel it still said, “Simulation Template – Book 1”.
Well maybe it’s more server related than user related. So I logged into the server, launched Excel & wouldn’t you know it, it said “Simulation Template – Book 1”. At this point I’m a little stumped. Like any stumped administrator…when in doubt, run Process Monitor.
I started ProcMon, launched Excel then stopped the capture. I filtered to only show excel.exe. Then I did a search for the word simulation. I got several hits but as I was going through them one jumped out at me. It was querying a value called LoadBehavior in HKLM\SOFTWARE\Microsoft\Office\Excel\Addins\SimulationClientAddIN.Connect. I right clicked the entry to jump to that spot in the registry. LoadBehavior was set to 3.
Not knowing what a valid value is for this I did a little searching & came across this site. Apparently 3 mean the add-in’s status is “Loaded” & its load behavior is “Load at startup”. Looking through the list 2, 8, or 9 also looked like viable options as well. So I changed the value to 2. I opened up Excel & sure enough the title bar now says, “Microsoft Excel – Book 1”!!!
According to the chart on that website leaving it on 2 leave opens the possibility that LoadBehavior could change back to 3 if the application successfully loads the add-in. But for now I’m going to leave it at 2. If the issue arrises again I may just change it to 9.