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.

By Darin McGinnes

Why would a communication technology that was conceived in the 19^th Century and perfected in the 20^th Century, still be important today in the 21^st Century? The simple answer: faxing is a guaranteed delivery technology that email has yet to achieve. For those of us who work in the industry, this might be stating the obvious. But for the uninitiated, most believe faxing is practically dead, after all aren’t we in the Information Age? My answer: not so fast, as faxing is still alive and well!

Don’t get me wrong, email is a wonderful, convenient, and easy to use technology that for many businesses that relied on faxing in the past, do not need to use it as much anymore. But if you’re in an industry such as medical, finance, legal, or construction, you know that email isn’t good enough when it comes to delivering or receiving important, time sensitive or legal documents. In this respect, one may wonder why faxing is superior to email. It all comes down to the fact that a fax is considered a legal document because the transaction can be confirmed while email cannot.

Let’s look at how a fax is transmitted vs. email. Email is built upon technology from the internet. It uses packet switch technology, which means it’s unreliable. Not that it’s ineffective, but the sender never knows for sure if the other side received the email as it is sent best effort only. Worse yet, it also could be easily intercepted by unscrupulous types. Faxing, on the other hand, is built upon technology from the tried and true public switched telephone network, the oldest communications network in the world. It uses circuit switch technology, which means that it’s reliable; both parties will know if the fax was sent successfully or not. Also, intercepting a fax transmission is much more difficult. And for those of you who are thinking: what about VOIP? Well, all that’s about is emulating a point-to-point circuit switched phone conversation over the packet switched internet. Circuit switched reliability is still intact.

One may ask if there is a better way to fax. After all, using traditional fax machines can be an unwieldy, inefficient process. Not to mention the difficult, time consuming process of integrating with business applications such as ERP, CRM, or document management systems. My answer to you is the fax server.

Either with an enterprise software solution like Open Text Fax Server, RightFax Edition or an appliance solution like Open Text Fax Appliance, FaxPress Edition, a fax server shields the inefficiency of sending or receiving faxes from the end user. It allows users to conveniently send and receive faxes from the desktop or leverage existing multifunction printers or scanners to send hard copy faxes. Furthermore fax servers seamlessly integrate with back office business applications that allow customers to realize a true paperless office, bringing the clunky fax into the 21^st century of technology and convenience.

To learn more, download one of our free whitepapers:

Implementing Fax over IP in your Organization

Network Faxing with Open Text Fax Appliance, FaxPress Edition

Recently I got the following comment on Twitter, regarding my post on building a custom MMC for building Alchemy databases remotely:

Can the mmc trick be implemented to add db’s to Alchemy Server instead of havin to do it manually? or, can it be automated?

The problem is that albatch can only really do what the Administrator application can do. The only real way around that is to use the API, and specifically the AuServerApi. You can use this in whatever language you like. Perhaps Powershell is convenient for you, or VB/VB.Net, or something else. I like to use C# with the Alchemy API. So below is some code for creating a database and then adding it to the Alchemy Server. I wrote this a few years ago for the Captaris Partner Conference in Kuala Lumpur, Malaysia.

As you can see, actually adding the database to the server is as simple as connecting to the server and then calling AddDatabase.

static Alchemy.Application auApp = new Alchemy.Application();
static AuServerApi.ApplicationClass auServer = new AuServerApi.ApplicationClass();

if (args.Length>0)
{

	string dbName = args[0];
	if (dbName.ToLower().EndsWith(".ald"))
		dbName = dbName.Substring(0, dbName.IndexOf("."));

	string dbPath = "c:\\databases\\" + dbName + ".ald";

	Alchemy.Database auDB = auApp.CreateDatabase(dbPath, dbName, "", false, "", "", "", false);

	auApp.Databases.Remove(dbPath);

	auDB.Logout();
	auServer.Connect("capadev", 0, 0, 0);
	auServer.AddDatabase(dbPath);
}
else
	Console.WriteLine("Please enter a database name");

I hope this is helpful. If you have any questions about any other Rightfax or Alchemy topics (or Workflow), let me know. You can do that on here or contacting me on Twitter where I am technovangelist.