Ozzie.eu

If you use Windows 7, create a new folder on your Desktop and name it "GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}". Open it to see the numerous options it gives you: administrative tools, backup and restore options, security settings.

It's a nice feature to perform super user tasks.

Following the subject of this here previous post, I'll discuss here a possible configuration process for DHCP reliant networks, with firewalls between segments.

The Windows Distributed Transaction Coordinator performs its communication using RPC communication, which by default means it requires 135 port and a set of dynamic ports above 1024.

A dynamic set of ports with no well-known range is not a best practice for network security. Given that, it's not a question of just asking the firewall administrator to open the default ports. We'll first configure a port range on the DTC service of the target machines.

On one of the hosts to configure:

• open the Windows Menu > Administrative Tools > Component Services;


• Drill-down to "My Computer", then select "Properties" from the mouse context menu;

• Select the "Default Protocols" tab. There should be a "Connection Oriented TCP/IP" item; Press the "Properties" button.

• Press the "Add" button and type in a suitable range like "50000-50200". This means DTC will use RPC thru ports 50000 to 50200.

Press OK on all windows and restart the server to assure it assumes the newly configured range.

Please note that this configuration has to be done on ALL hosts participating on the distributed transaction. If a given scenario has two separate MSSQL Server hosts and two more application servers, all four machines must have the port range configured on the DTC service configuration.

This step configured the port range for MSDTC on the target hosts. The next step is to request the firewall administrator to open the following ports between the two networks:

• 135: fixed standard port for RPC


• 50000-50200: the range we configured on the example. Could be another given range.

Besides the network firewalls, each hosts own Windows firewall configuration must be edited to allow the connections thru the newly configured port range. To do this, on each host, open the "Windows Firewall with Advanced Security" utility. If hints on that are needed, there's this article on Technet.

Talking about distributed transactions over the network, it's obvious TCP/IP communications ar involved. Consequently, this channel has to be enabled on the local DTC.

1. open the Windows Menu > Administrative Tools > Component Services;


2. Drill-down to “My Computer \ Distributed Transaction Coordinator \ Local DTC”, then select “Properties” from the mouse context menu;


3. Select the “Security” tab. The following options need to be checked: Network DTC Access, Allow Remote Clients, Allow Remote Administration


4. Still on the same window, on the Transaction Manager Communication: Allow Inbound, Allow Outbound, No Authentication Required


5. Check the Enable XA Transactions, uncheck the SNA LU option if you're no using legacy systems.

Press OK on all windows. It should be all done. This scenario still relies on dynamically assigned IP addresses and windows network architecture with WINS servers.

On the next and final post of the series, I'll consider a worst case scenario:

• static addressing of the hosts


• no naming servers available


• packet broadcast disabled


• firewall between application hosts and database hosts

It should be relatively interesting since everything is configured manually and it's a not so uncommon scenario for highly secured, tightly managed networks.

When using distributed transactions between distinct databases, using Microsoft Windows technology, one relies on the MSDTC - Microsoft Distributed Transaction Coordinator.

The main catch to this distributed architecture is that it works based on the hosts NetBIOS names, which is specific to the Windows operating systems and is used for network resource sharing and the like.

There are at least four relevant deployment scenarios concerning this technology:

1. Full stack on the same physical host


2. DHCP reliant network, all hosts on the same segment


3. DHCP reliant networks, with firewalls between segments


4. Static Address network with firewalls

The first scenario, full stack, isn't challenging because it assumes you have the Application Server and Databases all in the same machine. It can be imagined as the common scenario for developer machines which often have the IDE, DB Server and App Server all-in-one.

The second scenario where all hosts reside on the same network segment, usually a net mask of 255.255.255.0, requires only additional configuration if there are no WINS server available and network broadcast of packages has been disabled. Otherwise the default configuration will work fine.

Next post will discuss a configuration scenario with a firewall in between the Application Server and the Database Server.

Professionally I'm sometimes faced with the challenge of being assigned a task, without having the adequate tools to perform it. An example of that is working with XML files.

Not having acquired a commercial software like XML Spy, I had to find a free alternative. To open XML files, pretty-print them and check for issues, I adopted XML Copy Editor:



XML Copy Editor is a free editor that enables you to:

• open XML files
• edit your own XML
• check if the XML is well formed
• check the XML for compliance with a given schema

Having Netbeans 6.8 installed, with Glassfish V3 on a laptop running Windows 7, I had the following error upon starting the IDE:

CLI130 Could not create domain

Apparently, the J2EE development server domain could not be created. I opened a command prompt, navigated   to the Glassfish installation folder and executed the "asaadmin create-domain" to create a new domain. Still no luck! A lack of privileges prevented the new domain folder creation.

Next, I repeated the same step, but opened the prompt with the "Run as administrator" option. The domain creation went smoothly and after starting the IDE, the same error appeared because it would always try to start the default domain.

I carried on, manually starting my domain with the "asadmin start-domain" command and connecting to the server as if it was a remote server. But I was not pleased with the solution.

So, I tried to start the IDE with "Run as Administrator" option. And it worked. After all, it had a really simple work around.

As you might know, if you were following my blog on the previous address, I've migrated it from Wordpress to Blogger. The reason for doing so is just that Blogger let's you control the page's content with a finer grain, even write raw HTML it you want to.