Wade Wegner

I'll be honest ... I'm lazy.  I hate doing repetitive things over, and over, and over again.  So, while I was going through and installing Commerce Server 2007 on a new virtual machine, I decided to script out the creation of the local user accounts.  Before we get to the script, a little background ...

It is recommended that you create multiple accounts to handle the various roles within Commerce Server (such as the four web services, staging, etc).  In a production environment, these should be created as Domain accounts; however, in development (or the virtual world) you may not have access to, or wish to use, a domain. Consequently, you can create these users as local accounts as well.

Below is a script that will go ahead and create these local users for you (if I have time I'll create a similar script for domain accounts).  Copy the text (or download the link) and save it to a .vbs file.  You should be able to simply double-click the file, and then open up Local Users and Groups under Computer Management to double-check.

And there you have it!

CreateCS2007LocalUsers.vbs (2.46 KB)

I hope someone else finds this useful!

There comes a time in every Microsoft developers life that he/she will have to work with an Oracle database.  I hope that you find this to be a good experience; my experiences have thus far been a mixed bag, mostly because of my own ignorance.  Nevertheless, I've picked up a few things here and there, and figured that it would be worthwhile to post some of the top tips and tricks I've learned over the years.

In this post, I want to discuss how to setup an Oracle database server.  I am going to follow-up with a post on how to create an Oracle database.  I use those terms loosely, because the terminology within the Oracle world is different from the SQL Server world.  I promise I'll do my best to get it right, but chances are I'll make a mistake or two - please feel free to point out my gaffes.

So, without further ado, let's see go through the steps needed to install Oracle 9.2 (sorry, I don't have 10+) on Windows Server 2003 32-bit (note: there are many differences between 32-bit and 64-bit Windows, and my experience has shown that the following steps will not work in 64-bit Windows.  Perhaps I'll follow-up in the future if I figure out how to get it to work ...)

1. Secure a copy of Oracle 9.2.  I assume that you have a copy available through work.
2. Start the Oracle Universal Installer.  Click the Next button.
   
   
   
3. Confirm the installation destination (you'll need at least 3 GBs available for the installation) and click Next.
   
   
   
4. Select "Oracle9i Database 9.2.0.1.0", and click Next.
   
   
   
5. Select "Enterprise Edition", and click Next.  (Why?  Well, I don't have any compelling reason here - it's just what I've used to get things working ...)
   
   
   
6. Select "General Purpose", and click Next.
   
   
   
7. Leave the Port Number as 2030, and click Next.
   
   
   
8. Define the Global Database Name.  I choose "orcl", but feel free to choose whatever.  Make sure that the SID is unique - it's probably easiest to make it the same value as the Global Database Name.  Click Next.
   
   
   
9. Specify the Directory for Database Files.  I choose to leave the default value.  Click Next.
   
   
   
10. Unless you have a reason to change it, leave the "default character set" selected, and click Next.
    
    
    
11. On the Summary screen, click Install.  This installation process will take a little while.  Be patience.  Read one of my other posts, while you're waiting.
    
    
    
12. The next screen to appear is the Database Configuration Assistance.  On this screen, specify the SYS and SYSTEM passwords.  Do NOT click OK yet.
    
    
    
13. Before you click OK, click the Password Management Button.  Specify passwords for SYS, SYSTEM, and DBSNMP (SCOTT too, if you'd like).
    
    
    
14. Once you get to the End of Installation, click Exit.
    
    
    
15. After you click Exit, the Oracle Enterprise Management Console will start.  Check and make sure you can log into your Oracle database server by expanding databases, right-click ORCL (or whatever you called it) and click Connect.  Enter the "system" Username, and change Connect as from "Normal" to "SYSDBA".  Click OK.
    
    
    
16. If you were able to successfully connect to the Oracle database server, then restart Windows.  There's a number of reasons to do this, including updates to the PATH environment variable.

And that's it!

Now, I realize that this installation procedure pretty much accepts the defaults, and clicks next.  However, at least you have the benefit of knowing that this procedure does work, and will prepare you for the next step: configuring Oracle databases, tablespaces, users, and user access.

Best of luck!

Have you ever received the following error when you tried to access a UNC path?

XXXXXXX is not accessible. You might not have permission to use this network resource. Access is denied.

I found that if I logged into some of our production servers, I was unable to connect to a UNC path on the file server (a different machine), even though I was able to access these resources locally.  The only difference I could find was that in order to access the production servers I had to use a different login than my local login (e.g. my local login had acess to the file share, but not the login I used for the production boxes).  And, as I do not have administrative rights in this domain (nor were any administrators available to assist) I couldn't change the rights to the file server to give my production user access.

So, I needed to find a way to access the file share as my local account.  Unfortunately, I couldn't log into the production server with my local account (a good thing, actually), and I couldn't get Explorer.exe to runas my local account while on the server.

Then I decided to try and mount the share as a driver.  Here are the steps I took:

1. Opened up My Computer, the click Tools --> Map Network Drive ...
2. For the folder, specify your UNC share.  Then, instead of clicking finish, click the "Connect using a different user name".
   
   
   
3. In the Connect As screen, specify your local account that has the ability to access the UNC share.
   
   
   
4. Click OK, then Finish.

These steps mount the UNC share using your local account.  As a result, I was able to access the file server on the production server, which I previously hadn't been able to do.

If you find yourself in a similar situation, these steps may provide you with a temporary work around.

I hope this helps!

I learned a new twist to the following error message today:

The adapter "SQL" raised an error message. Details "Unable to enlist in the transaction. (Exception from HRESULT: 0x8004D00A)".

This can occur in a scenario where your BizTalk server attempts to connect to a separate SQL Server database and execute a distributed transaction.  In order for this to work the BizTalk server must have the ability to "hand-off" the transaction to SQL Server.  Typically, when you receive this error, it's because the Distributed Transaction Coordinator (DTC) service is disabled or network DTC access is disabled.  These are the default settings in Windows Server 2003.  Take a look at the following article:

http://support.microsoft.com/?kbid=816701

There's an additional twist to this scenario.  I found myself in a situation where I was receiving this error but had DTC setup correctly on all the machines in my BizTalk group and SQL Server cluster.  Nevertheless, the distributed transactions failed.  Then I found the following article:

http://msdn2.microsoft.com/en-us/library/aa561924.aspx

Turns out that, in order for DTC to work, the SQL Server must be able to resolve the NetBios name of the client (the BizTalk servers, in this case).  If it cannot resolve the NetBios name the transaction will fail.  In my environment, a firewall prevented the ability to resolve the NetBios name to an IP address thereby preventing the distributed transaction from processing.

To resolve this, I updated the HOST files on the SQL Server cluster so that they were able to resolve the NetBios names to an IP address.  Literally, moments after saving the HOST file, all my records started getting written into the database.

As I said, a different twist to a common problem.

I hope this helps!

As I mentioned in a previous blog, I've been setting up BizTalk 2006 in a 64-bit Windows Server 2003 environment.  This BizTalk solution communicates to AS/400 and Oracle, so I've been using the Microsoft BizTalk Adapters for Enterprise Applications (for Oracle connectivity) as well as Microsoft BizTalk Adapters for Host Systems (for AS/400 DB2 connectivity).

Setting up these adapters has not gone extremely well in the 64-bit O/S (whereas a 32-bit O/S is quite simple to configure).  I've been set back about a week because many different issues related to the 64-bit environment (and a few other issues).  In this post, I want to explain the issues I've encountered with regards to the Oracle adapter in a Windows Server 2003 64-bit environment.

This post assume that you've already installed your Oracle client.  Check out my post Using the "ODBC Adapter for Oracle Database" in BizTalk 2006 for information on how to install the client.  However, if you're installing on a 64-bit machine, stop after you install the client.  The 64-bit world is quite different ...

1. Install the .NET Framework 1.1 and SP 1.

The Oracle adapter requires the .NET Framework 1.1 and SP 1.  My 64-bit environment didn't have the .NET Framework 1.1 installed, so this was an additional step I had to take.  This was the easiest of all the steps I had to take ...

2. Create the ODBC connection.

Turns out that you cannot simply run Data Sources (ODBC) from Administrative Tools.  You have to run %WINDIR%\SysWOW64\odbcad32.exe, which invokes the 32-bit version of the Data Sources (ODBC) GUI.  See my post Adding ODBC connections in Windows Server 2003 64-bit for more information.

3. Install the Microsoft BizTalk Adapters for Enterprise Applications.

I only installed Oracle (r) Database.  Surprisingly, with the .NET Framework 1.1 and SP 1 installed, this goes very well.

4. Update registry settings for the Microsoft BizTalk Adapters for Enterprise Applications.

Turns out that some of the registry keys that are written during the installation are wrong (or rather, they're not interpreted correctly).  Browse to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BizTalkAdapters.  Two of the values, InstallDir and InstallPath, need to be changed.  Do the following:

1. Change InstallDir from "C:\Program Files (x86)\Microsoft BizTalk Adapters for Enterprise Applications" to "C:\Progra~2\Microsoft BizTalk Adapters for Enterprise Applications".

2. Change InstallPath from "C:\Program Files (x86)\Common Files\Microsoft BizTalk Adapters for Enterprise Applications\" to "C:\Progra~2\Common Files\Microsoft BizTalk Adapters for Enterprise Applications\".

Yes, for some reason, you have to change "Program Files (x86)" to "Progra~2", probably because the Adapter isn't written very well.  If you don't update these registry settings, you will most likely get the following error:

The description for Event ID ( 0 ) in Source ( Microsoft BizTalk Adapters for Enterprise Applications ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event:     Exception occurred:
            Error Code: 12154 (0x2f7a)
        08004 : [Oracle][ODBC][Ora]ORA-12154: TNS:could not resolve service name.

5. Update additional registry settings to fix permission errors if you are using domain groups for authentication.

Your domain groups will not have access to the Oracle adapter by default.  In order to allow the runtimeagent.exe (which is the executable that is spawned and runs the Oracle adapter) to run appropriately, it needs to be able to access a registry key.  See the following article for more information: http://support.microsoft.com/?id=923650.

Do the following to resolve this issue (from the article):

1. Locate the following registry key: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\BizTalkAdapters\Config

[** Thanks to Steef-Jan Wiggers for noting that I forgot to display the 32-bit path in the Wow6432Node key]

2. Right-click the registry key that you located in step 1, and then click Permissions.

3. On the Security tab, click Add.

4. Type the domain group or the domain user account that is configured as the BizTalk host instance, and then click OK.

5. On the Security tab, click the domain group or the domain user account that you added in step 4, click to select the Read check box, and then click OK.

If you don't update these registry settings, you will most likely get the following (unhelpful) error:

"RuntimeAgent: Error trapped in constructor: No connection could be made because the target machine actively refused it"

Error transmitting message: No connection could be made because the target machine actively refused it

6. Update the security permissions on your Oracle folder.

This is the most bizarre step of all, and it's not particular to the 64-bit environment.  Oracle software requires that you give the Authenticated User privilege to the Oracle Home.  In most cases, your Oracle agent will not be the Administrator account (or at least, I hope it's not).  However, there seems to be an issue with the permissions associated to Authenticated Users.  Consequently, the agent you specify to run the Oracle "runtimeagent.exe" is unable to gain access to the folder.  You might see the following error:

IM003 : Specified driver could not be loaded due to system error  5

To resolve this problem, you have to do the following:

1. Log on to Windows as a user with Administrator privileges.

 

2. Launch Windows Explorer from the Start Menu and and navigate to the ORACLE_HOME folder. This is typically the "Ora92" folder under the "Oracle" folder (i.e. D:\Oracle\Ora92).

 

3. Right-click on the ORACLE_HOME folder and choose the "Properties" option from the drop down list. A "Properties" window should appear.

 

4. Click on the "Security" tab of the "Properties" window.

 

5. Click on "Authenticated Users" item in the "Name" list (on Windows XP the "Name" list is called "Group or user names").

 

6. Uncheck the "Read and Execute" box in the "Permissions" list under the "Allow" column (on Windows XP the "Permissions" list is called "Permissions for Authenticated Users").

 

7. Re-check the "Read and Execute" box under the "Allow" column (this is the box you just unchecked).

 

8. Click the "Advanced" button and in the "Permission Entries" list make sure you see the "Authenticated Users" listed there with:

 

Permission = Read & Execute

Apply To = This folder, subfolders and files

 

If this is NOT the case, edit that line and make sure the "Apply onto" drop-down box is set to "This folder, subfolders and files". This should already be set properly but it is important that you verify this.

 

9. Click the "Ok" button until you close out all of the security properties windows. The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.

 

10. Reboot your computer to assure that these changes have taken effect.

Yes, I was in as much shock as you are.  Uncheck a flag, and then re-check it.  I lost almost three days because of this bug.

That's about it!  A series of (mostly) undocumented steps that are required in order to get the Oracle adapter to function in a 64-bit environment.  Fortunately, I had some great support from the escalation engineer's with the Microsoft Product Support Services group.

I hope this post helps someone else avoid much of the pain and agony I had to go through ...

Best of luck!

We've been deploying a BizTalk 2006 solution to a x64 system and, while BizTalk 2006 itself has no problems, I've had a lot of problems related to the BizTalk Adapters for Host Systems and the BizTalk Adapters for Enterprise Applications.  I plan to write a number of posts in the near future discussing these problems (once we have them all resolved).  In the meantime, I wanted to share this little tidbit I've learned about ODBC on 64-bit windows.

It's important for you to know if your application is going to run as a 32-bit or 64-bit application.  There are two different repositories for ODBC connections, based on the drivers you've installed and the client that will run them.  32-bit applications will only see ODBC connections from the 32-bit side, and 64-bit applications will only see ODBC connections from the 64-bit side.

32-bit applications register ODBC connections to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI

64-bit applications register ODBC connections to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI

Adding these keys is initially tricky, but if you understand the above then it should make sense.  Typically, you go to Start --> Administrative Tools --> Data Sources (ODBC) to create your ODBC connections.  And this is fine if you want to create 64-bit ODBC connections.  Any ODBC connection created using the Data Sources (ODBC) link will get created in the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI key.  This is because it calls the program %WINDIR%\System32\odbcad32.exe.  However, this program will not create 32-bit ODBC connections.

To create 32-bit ODBC connections, you have to run %WINDIR%\SysWOW64\odbcad32.exe.  Adding an ODBC connection through this application will create the ODBC connection in the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI key, and allow your 32-bit applications to see and use the ODBC connection.

I'm still getting used to the concept of WOW and how it runs 32-bit applications on an x64 system.  This information may not be news to some of you, but it presented a challenge to me.

I hope this helps!