ODBC connections allows a Windows computer to connect to a data source. Typically the datasource is a database. In a 32-bit version of windows, you just create the ODBC connection and it works. In a 64-bit version of windows, then it is more complex.
In a 64-bit version of Windows, you need to create an ODBC connector to that matches the application. For a 64-bit application, you create a 64-bit ODBC connection. For a 32-bit app, you create a 32-bit ODBC connection.
The most common problem is creating an ODBC connection by using the ODBC Data Source Administrator tool in control panel and then you are unable to see of view the ODBC connection from a 32-bit application. The ODBC Data Source Administrator tool that you can open from control panel creates only 64-bit ODBC connections. To create 32-bit ODBC connections you need to run Odbcad32.exe from the C:\Windows\SysWoW64 folder.
Thursday, April 22, 2010
Bad McAfee, Go to Your Room
McAfee sent out a bad update yesterday that wiped out a Windows System file (svchost.exe) and rendered Windows very unhappy. The system I was dealing with initially lost network connectivity and many programs stopped running properly. I ran a Repair installation for XP to fix the issue.
They now supply a tool to fix the problem: http://vil.nai.com/vil/5958_false.htm
You figure that sort of thing would show up in testing. XP SP2 and XP SP3 were affected.
They now supply a tool to fix the problem: http://vil.nai.com/vil/5958_false.htm
You figure that sort of thing would show up in testing. XP SP2 and XP SP3 were affected.
Friday, April 9, 2010
So, you deleted that object, eh?
Ok, so let's say, you accidentally deleted a group. Or, thought it wasn't needed and turns out that it was. People can no longer access files, and you can't remember exactly which files the group was assigned access to. The good news is that you can recover from this.
Option 1 - Restore AD objects from backup
If you have a system state backup of a DC (and you should!!), you can restore the deleted object from backup. Then you mark it as authoritative. However, to have group memberships restored correctly, you need to perform an ugly process where objects are restored twice to make sure the links are correct. Also the DC needs to be down during this mess. Doable, but not the preferred option.
Detailed info: http://support.microsoft.com/kb/840001
Option 2 - Reanimiate the deleted object
Yes, just like a zombie, you can bring back an object from the dead. And also like a zombie, it is a shadow of its former self. Only some properties are kept in the deleted object. When you reanimate it, many properties are lost. However, it does keep the SID. So, a reanimated objects retains file permissions that were assigned to it.
In the case of a reanimated user, the group membership is lost. I expect that you would also need to recreate the membership of a reanimated group, but I haven't tried it out recently.
Detailed info: http://www.microsoft.com/technet/technetmag/issues/2007/09/Tombstones/default.aspx
Simplified reanimation with ADRestore: http://www.microsoft.com/technet/sysinternals/utilities/AdRestore.mspx
Option 1 - Restore AD objects from backup
If you have a system state backup of a DC (and you should!!), you can restore the deleted object from backup. Then you mark it as authoritative. However, to have group memberships restored correctly, you need to perform an ugly process where objects are restored twice to make sure the links are correct. Also the DC needs to be down during this mess. Doable, but not the preferred option.
Detailed info: http://support.microsoft.com/kb/840001
Option 2 - Reanimiate the deleted object
Yes, just like a zombie, you can bring back an object from the dead. And also like a zombie, it is a shadow of its former self. Only some properties are kept in the deleted object. When you reanimate it, many properties are lost. However, it does keep the SID. So, a reanimated objects retains file permissions that were assigned to it.
In the case of a reanimated user, the group membership is lost. I expect that you would also need to recreate the membership of a reanimated group, but I haven't tried it out recently.
Detailed info: http://www.microsoft.com/technet/technetmag/issues/2007/09/Tombstones/default.aspx
Simplified reanimation with ADRestore: http://www.microsoft.com/technet/sysinternals/utilities/AdRestore.mspx
Thursday, April 8, 2010
Intermittent DNS lookup failures for Exchange Server
I have one ISP where we have intermittent problems delivering messages to mailboxes hosted by that ISP. It is something related to DNS lookups, because when I clear the cache on our DNS server, the problem goes away. So, presumably it's changes on their end that cause the issue.
By default the Windows DNS server caches DNS lookups for 24 hours. However, I don't want to be manually clearing the cache on this each time the error occurs (or wait up to 24 hours to automatically resolve). The solution: modify the cache TTL.
In all of the forward lookup zones that you create, you can set the TTL for the zone or individual records. However, in the cache, you can't set the TTL by using the DNS Manager console. You can either use dnscmd.exe or edit the registry.
In HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters, create a REG_DWORD value named MaxCacheTtl and provide a value in seconds. I did not find any documentation saying that this registry key works in Windows Server 2008, but tested it, and it does. There is documentation for Windows Server 2003 and earlier versions.
After setting the registry key, you need to restart the DNS server for the change to take effect.
UPDATE: A client started having this issues and I found a knowledgebase article that talks about this exact issue. Oddly the recommendation is to set the MaxCacheTtl at two days rather than shorter as I had done. See here: http://support.microsoft.com/kb/968372.
There is also a similar issue with 2008 R2 and 2008 R2 SP1 for which there is a hotfix. See here: http://support.microsoft.com/kb/2508835/en-us
UPDATE#2: We have now had several clients with this problem and the solution has always been to implement the MaxCacheTtl at two days. The hotfix has not ever resolved the issue for us.
By default the Windows DNS server caches DNS lookups for 24 hours. However, I don't want to be manually clearing the cache on this each time the error occurs (or wait up to 24 hours to automatically resolve). The solution: modify the cache TTL.
In all of the forward lookup zones that you create, you can set the TTL for the zone or individual records. However, in the cache, you can't set the TTL by using the DNS Manager console. You can either use dnscmd.exe or edit the registry.
In HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters, create a REG_DWORD value named MaxCacheTtl and provide a value in seconds. I did not find any documentation saying that this registry key works in Windows Server 2008, but tested it, and it does. There is documentation for Windows Server 2003 and earlier versions.
After setting the registry key, you need to restart the DNS server for the change to take effect.
UPDATE: A client started having this issues and I found a knowledgebase article that talks about this exact issue. Oddly the recommendation is to set the MaxCacheTtl at two days rather than shorter as I had done. See here: http://support.microsoft.com/kb/968372.
There is also a similar issue with 2008 R2 and 2008 R2 SP1 for which there is a hotfix. See here: http://support.microsoft.com/kb/2508835/en-us
UPDATE#2: We have now had several clients with this problem and the solution has always been to implement the MaxCacheTtl at two days. The hotfix has not ever resolved the issue for us.
Subscribe to:
Posts (Atom)