Sep 222011
 

Chances are, if you happen to work within the a Server 2008 or R2 environment and have ever needed to reset a profile you have seen the following error message. “The User Profile Service service failed the logon. User profile cannot be loaded.”

Unlike the good ol’ days in Server 2003 where you could just at will delete profiles from “c:\documents and settings” its now not a great idea to purge any profiles in 2008 (“c:\users”) without properly doing it. I help is needed, here are several ways to properly delete profiles in Server 2008, R2, and beyond.

  • [GUI Profile Reset]
    • Start > Run > type in ‘control’ and click on OK
    • Locate the “system” icon and double click to open.
    • Locate “Advanced system settings” on the left hand side and open.
    • Click on “Settings” under “User Profiles” in the “Advanced” tab.
    • Locate the profile you want to reset and click on “Delete” to purge the profile.
  • [Manual profile deletion]
    • Start > Run > type in ‘c:\users’ and click on OK
    • Make sure the user is no longer on the server. Then locate the profile and delete.
    • Next we need to open the registry > Start > Run > type in ‘regedit’ and click on OK
      • Expand > HKEY_LOCAL_MACHINE
      • Expand > SOFTWARE
      • Expand > Microsoft
      • Expand > Windows NT
      • Expand > CurrentVersion
      • Expand > ProfileList
    • Locate the users SID and delete. There is a very good chance you will see the key ending in ‘.bak’.
    • To confirm you have selected the proper profile click on the key and read the ‘ProfileImagePath’ [REG_Expand_SZ]. You will see the users path, if the profile name matches what you deleted in “c:\Users\”, you will have a match.

 

Aug 172011
 

In an attempt to migrate a very old Oracle based application which I believe was built in powerbuilder, we were getting several very odd errors. Keep in mind we are attempting to run this application on a newly built Server 2008 R2 (x64) Enterprise server with SP1 installed. Even more interesting is we needed to successfully install the Oracle 10.2 (10G) package which is a 32 bit application on an R2 64bit OS.  Everything about this application screamed impossible. So did nearly ever search we did on the Internet.  Apparently after several hours of analysis, its not that difficult to resolve. See below for the full details.

Error:
Error Number: -2147467259
Error Description: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Error Source: Microsoft OLE DB Provider for ODBC Drivers

  • To correct:
    • Assure the TNS_ADMIN key is in place
      • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE
        • Key Name:  TNS_ADMIN
        • Key Type: REG_SZ
        • Key Value: c:\oracle\ora102\NETWORK\ADMIN\ or the value can be any UNC network path if you happen to be working in a shared environment.
      • (optional) HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE
        • Key Name:  TNS_ADMIN
        • Key Type: REG_SZ
        • Key Value: c:\oracle\ora102\NETWORK\ADMIN\ or the value can be any UNC network path if you happen to be working in a shared environment.

Once the values are in place and you have confirmed your updated tnsnames.ora is in place go ahead and restart your application. You should have full functionality with your Oracle 10G client.

What went wrong: For starts, running the Oracle 10G client on Server 2008 R2 (x64) is asking for trouble. Even oracle has an alleged update which is apparently difficult to acquire for any firm without a contract with “my oracle support”. I guess this is by design which frankly is completely annoying and one of the reasons I dislike Oracle.  Anyway, so in theory – Oracle broadcasts a device name via LDAP. When you attempt to connect to that name the local drivers first look at LDAP [ldap.ora] for the settings needed to resolve the name via LDAP. If an LDAP entry is not found – your client will by default then use the TNSNAMES.ora for to acquire the needed server name. This is percicely what was going on in this situation and why we had to force the oracle client to look at a path we specified. Good stuff and yet one more reason why its time to start migrating our code to a 64 bit platform.

 

 

 

© 2012 random technology [RT] technology documentation

Optimized by SEO Ultimate