OpenText Fax & Document Distribution Group

When I came in today, a colleague asked me a bizarre question. I had to think about it and as we discussed it, several others joined in giving their own opinions. All of us had differing opinions on what would happen. Naturally of course, I knew that I was correct and they were all wrong, but I wanted to be able to prove it. First, let me tell you what the problem is:

There is a customer who is synchronizing their users from Active Directory into Rightfax. Now many of the users are only working for a short time then they leave. Sometimes they don’t leave but move to a different part of the organization. So what happens to that Rightfax user when they are moved in AD from one group to another? The customer has several Sync Mappings targeting different groups and each mapping defines a special coversheet, group membership, etc. When the user is moved to a different AD group, is there a way to get the new RF group membership to be applied?

What do you think? Some of my colleagues said no, there was no way to synch that AFTER initial user creation. One said that a second user would be created even though they were the same user.

Well, the answer is both yes and no. Using the standard way of configuring the Sync Module, the answer is no. But after spending about 30 minutes looking into it using only publicly available resources (well, public for registered users), I found a solution. But before I go into the solution, let me tell you why the standard answer is no.

The Sync Module is part of Rightfax that synchronizes users from Active Directory or LDAP to Rightfax. For more information about the Sync Module, see my previous article on this topic. There are about 12 standard attributes that are synched from AD to Rightfax. But group membership, coversheets, etc are not in that list of 12. For those things to be set, the standard answer is to set them in a special default user for that mapping, and then all of those details will be set. But that default user is only referenced on initial creation of the Rightfax user.

So here is how to solve this problem. Before actually attempting anything like this, test on a non-production system. In order to set anything after the initial user creation, you have to edit the XSL document that defines the mapping. Now that may sound scary, but really its not. Here is the entire process I used to figure it out:

1. First go to the directory that contains the XSL files and make a copy of one of them as a starting point. The directory is going to be CapaSync\config off of you Rightfax program directory.
2. Open the file in an editor. I happen to use PSPad, but notepad would be fine as well. Find any existing line that starts with <xsl:template. Insert this on the next line:

   <attr name=""> <value></value>  </attr>

3. Now we need to figure out how to fill in the details. I want to use this to synchronize group membership. All the users in one AD organizational unit will be a member of one RF group. Members of another OU will be a member of a different RF group. What I need to find is the attribute to use to set the RF group. The list of all possible attributes lives at this page on the Open Text Knowledge Center. Login using your credentials to see the article. If you don’t have the rights to see the article, then contact your Open Text representative to organize those rights.
4. I can see that the only item that starts with the word Group is GroupID and that the value will be an integer. So now my XSL has become:

      <attr name="GroupID">   <value></value>   </attr>

5. I still need a value to use. I took a look in the database to see what my choices were. While waiting for SQL Management Studio to open, remember this. DON’T WRITE ANYTHING TO YOUR DATABASE!! Reading is not a problem, but writing to your database means breaking stuff. Inside the Groups table I could see a few things that might work. The most obvious was a column called GroupID. This was the actual name of the group. By the time I saw this, I had forgotten about the need for the value to be an int, so I tried it. Nothing happened. In the event log I saw an error saying there was a conflict with the column ‘handle’. That’s when I remembered the need for an int. Well, the handle column contains ints and its usually how we refer to objects in Rightfax. So I tried that.
6. The handle for my first group was 100663298 so my XSL now became:

      <attr name="GroupID"> <value>100663298</value> </attr>

Guess what, this worked. I then made a second copy of the XSL file and set up a second GroupID. Soon after I moved a user from the first group to the second in AD, the group membership in Rightfax changed as well.

The real secret to get this to work is finding the right value in that KC article, then putting a value in that it expects. A little trial and error and you should have a more customized XSL that works for your needs.

Update May 4 2011: This blog was written about RightFax 9.4 base. By Base, I mean without any Feature Packs or Service Releases. Around the time of this blog, SR2 was released which encrypted the password even with regular TCP/IP connections.

One of the questions that sometimes comes up in class is about the security of the network connection between FaxUtil and the Fax Server. Some companies are generally not concerned about securing the connection to the Fax Server since it is inside the firewall and the company’s employees are trusted. Other companies need to know that all communications between every individual and server is completely secured and encrypted.

Open Text Fax Server supports two methods of securing communications from FaxUtil to the Server. You can see both of these when you go into FaxUtil, close the connection, then choose to open a new connection. There is a dropdown for protocol and the two choices are TCP/IP and Secure TCP/IP.

If you choose TCP/IP, which happens to be the default, all communications between the server and the client will be over port 10520 and most of it will be sent in plain text. What does plain text mean? Well if you use a tool to view all the messages that go across the wires, you can see the plain text messages and read them without the need for any special training. Its all right there in the open.

Before you start to panic, much of the traffic over the internet is sent in plain text. You know all those messages you send to friends using MSN Messenger? Plain Text. Oh, you use AOL Messenger? Plain text again. Yahoo Messenger? Yup, plain text. In fact most of your web viewing is done in plain text. The reason why that is often the default with so many network applications is that it is simply more efficient than the alternative.

What is that alternative? Well, there are many choices when you get down to the nitty gritty details, but they are usually out of your hands. The developers of the products you use decided what was the best option. But the communication is basically just encrypted in a way that only the recipient and maybe the sender can understand it.

A couple of paragraphs ago, I mentioned that you could use a tool to see the traffic as it goes over the wires. There are several tools available, including some that cost quite a bit of money. But two of the best are both free: Wireshark and Microsoft’s Network Monitor 3. I use Wireshark a lot, especially when working with Fax over IP. You can get it from http://www.wireshark.org.

When you open up Wireshark and start what is called a trace, you will probably get overwhelmed with information. An easy way to filter this down is to type DCERPC into the filter box at the top. This will configure Wireshark to only show you the RPC messages being sent over your network. To filter it down further to only RPC messages going to and from your computer, type this into that filter textbook: dcerpc && ip.addr==10.9.8.1 (replacing 10.9.8.1 with whatever your IP address is).

I am running Wireshark from the server running the Fax Server. I have FaxUtil running on a different machine. I have one user I created with a password that is not linked to an Active Directory user. So I start up a Wireshark trace and enter my filter text. Now switching over to the FaxUtil PC, I try to start up FaxUtil and enter my credentials. Now back over in Wireshark, here is what I see about 15 lines down from the top.

I logged in as Administrator and the password is thisismypw. But you knew that because you can see that plainly in the trace. Kind of scary, isn’t it?

There are two easy fixes for this. First you can switch over to using Secure TCP/IP from FaxUtil. This will encrypt the messages between the server and the client and use port 10521. Here is the comparable packet after turning on Secure TCP/IP. There is no way I can read that and I am pretty sure you cannot read it either.

So why don’t we encrypt all communications by default? If its so easy to make these communications completely unreadable, surely there must be a reason not to encrypt it all. Well, there is a bit of a reason. It adds a bit of overhead on the network. In a brief test while writing this post, I saw that the overhead was about 20 percent. For some bandwidth deprived networks, 20% overhead may be a bit too much. But if you have the bandwidth and you don’t have users linked from AD, then definitely turn on that feature.

I mentioned there were two ways to configure Rightfax to not send passwords in plain text. The first is Secure TCP/IP. The other is to link your users to Active Directory. This bypasses the need to transmit passwords completely. Instead, we are able to see who you are logged in to your Windows client as. If you were able to log in to Windows, then we make the reasonable assumption that you must be that person. If that person is linked to a specific Rightfax user, then it is that user’s mailbox you will see in FaxUtil. There is no 20% overhead in network bandwitch and no passwords are sent in plain text.

Those are your options for securing communications between FaxUtil and the Fax Server. I hope you found this useful and if you have any other ideas for future post, let me know with a comment to this blog. You can also reach me on Twitter where I am technovangelist.

I remember a few years ago, a student in New Zealand asked me if I could help them with a bizarre request. They needed to have several groups of users in the organization with different fax settings. Now that’s not all that weird on its own, but they wanted all those settings to apply automatically as soon as a new employee started working at the company. Since then, I received similar questions from students around Asia, Europe and every where else I deliver trainings. It’s a common request and it seems that many people don’t know that what they are asking is a built in feature of RightFax.

The magic of that functionality happens in the module called the Captaris Sync Module. Its really pretty easy to set up and once initially configured, it just works without much additional involvement. The step that most people don’t realize is possible is that you can create multiple groups of synchronized users.

Before I show you how to set this up, let me show you a portion of my Active Directory. In the screenshot on the left, you can see an organizational unit I created call AllUsers. Within that OU, I have other OUs for It, Marketing, and Sales. Each of those OUs have a couple a users defined. What I want to do is set up synchronization so that the users in each OU get a different cover sheet, general fax number, and other settings.

Back on my RightFax server, I have double-clicked on the Sync Module in my list of services in Enterprise Fax Manager. That brings up the configuration dialog shown here. When you click the Sources & Destinations button, you can enter each place you want to grab users from, and where you want them to go to. At first it seems that this has a bit of unnecessary overhead, since it may seem obvious that you want to bring users from AD to Fax Server. But the fact that you have to specify this allows you to create multiple synchronization groups.

I’ll create two sources and two destinations, entering a name Sales and Marketing for each pair. The result can be seen in the Sync Sources and Destinations window shown on the left. When you create these, you’ll see that you can also create LDAP sources. LDAP, in case you aren’t familiar with it, is an industry standard directory server technology that many companies have implemented. In fact, Active Directory is also an LDAP server, but as with most standards, they look better on paper than in real life. Although it’s a ‘standard’, most LDAP providers don’t actually agree on how to implement the technology. The flavor of LDAP that we are tuned to out of the box is Lotus Notes LDAP, but its easy to tweak that if you are familiar with LDAP.

Once you have your sources defined, you create a mapping that tells the Sync Module which source and destination to use together. I’ll link the two Marketing items together, as well as the two Sales items. Click on Browse to show the different types of mappings we support out of the box. To tweak one of the mappings, you can use a text editor to modify the XSL file. There is an option on that dialog to set your schedule. For this environment, I am choosing Continuously. You should experiment in your environment to see what works best for you. The current synchronization tool is much more efficient than previous versions, but depending on the hardware used, number of users in your AD, and other factors, you may have to limit your schedule a bit. After you add your two pairs of mappings, you’ll see them listed under mappings and you’ll see two new tabs for each pair.

When I go to the AD – Marketing tab, I can choose which users I want to bring over. I want to make sure I specify that only the Marketing OU is going to be synched. In my AD, I have 2 users per OU, but in a real-world OU, its not unusual to have hundreds or maybe thousands of users in an OU. Lets say that you have 100 users in Marketing. Half of the users are on Exchange 2010, and the other half are Lotus Notes clients. You could have a group called Exchange users, then choose to include that group or exclude it. If you choose to Include or Exclude groups, make sure that the groups have the users as direct members. We won’t see users that are members of sub-groups.

Now switch to the corresponding RF tab, and fill in the Rightfax server to add users to. You also want to an administrator to use to create the new users. On the Users tab under RF-Marketing is where the real magic is configured. When you create users in EFM, they will be created based on the Default user template. But in the sync module, they can be created based on any user you choose. I created a Marketing Default as well as a Sales Default. Each of these default users have different cover sheets defined as well as other settings such as permissions.

Now click OK and within a few seconds, I see new users showing up in EFM. If you go to edit those users, you will find the cover sheet and other settings have all been configured as you expected.

I don’t know of a limit to the number of pairs you can have in this tool but you probably won’t reach it. This can be a very useful tool to use in many different implementations of RightFax and I look forward to hearing about how you are using it at your company.