How to Write from Domino to File Servers without Extended Rights

The Problem

We have a file on our data file server which is used by our Microsoft Word templates to generate a whole bunch of different documents. Until recently, updates to this file have been mostly manual but now we're getting one of our new systems to perform them directly.

The problem is that the file is on a different share and a different server. The agent runs fine manually but when it runs on the server, it fails.

BTW: All our data servers and domino servers are currently Microsoft Windows Server 2003.

Why it Fails

It doesn't matter who is logged onto your domino server when you're write out a file from an agent running on the domino server because it won't be using their credentials. Since Domino is running as a service, it will be running using a different set of credentials entirely - most likely; "System".

Since "System" is a local (to the server) user rather than a domain/directory user, you can't grant it access to the rest of your network. Even if you could, this would be a very dangerous thing to do since it would grant everything running on the server access to your network.

Option 1 - Upgrade the Rights of the Domino Service

I really can't recommend this option because in my opinion, it opens some nasty security holes. I'm mentioning it mainly because in the course of my investigations, I discovered that some people use this method.

The way this method works is simple, you create a domain account with "logon as a service" rights and then modify the properties of the Lotus Domino Service (in the services control panel) to logon using these credentials.

That's it. Simple, no fuss - easy.

The main drawbacks to this method are that;

1. Instead of simply granting your one application access to the resources you need, you've now granted your entire domino infrastructure write access to your file servers. In the unlikely event that your server is compromised (or the more likely event that one of your apps has some dodgy code) you could erase files on your file servers, or even fill up the hard drives and cause them to crash.
   
   
2. If for some reason, you expire, change password or adjust the rights of the user being used by the server, you may suddenly find that your domino server stops working. If your Domino and Windows domain administration teams don't communicate well, they may be completely oblivious to the reasons for the failure.

Option 2 - Write Local, Move Via Service

This was the option I ended up using. It's more complex than the original method but it's more secure and easier to fix if a problem occurs.

Write Locally

First chose a folder where you're going to write temporary files on your local domino server. D:\TEMP is a good choice, though you should consider having a sub-folder for your app. (eg: D:\temp\travelplanner).

Note that C:\temp is a bad choice. You should avoid writing temporary files to the operating system drive of the server - if you fill it up, the server could crash.

Create a Batch File to update the file

You can run the batch file from your domino server or from a file server. It doesn't matter.

Here's mine;

-----------------------------COMMUNITY.BAT--------------------------------------

1. @echo off
2. cls
3. echo Checking Templates INI file on Community and M Drive.
4. echo n | COMP \\domino4\D$\temp\Community\community.ini D:\Data\Public\Templates\community.ini | FIND "Files compare OK" > nul
5. IF ERRORLEVEL 1 GOTO NOTSAME
6. IF ERRORLEVEL 0 GOTO END
7. :NOTSAME
8. echo Copying Templates INI file from Community to M Drive.
9. copy \\domino4\D$\temp\Community\community.ini D:\Data\Public\Templates\community.ini
10. echo.
11. :END
12. echo.
13. echo.

END-----------------------------COMMUNITY.BAT--------------------------------------

Explanations

I'll just explain a few things....

You shouldn't have line numbers, I've only added them so that you can more easily see which lines wrap and which don't.

The source file on the domino server (written by domino) is called;

\\domino4\D$\temp\Community\community.ini

The Target file on the file server (used by internal users) is called;

D:\Data\Public\Templates\community.ini

Note that since the target is a local reference and the source is a UNC Name, it implies that the batch file is being run by the target server. This makes sense since we really don't want to introduce additional processing to the domino server.

In step 4, we don't want to copy the file if it hasn't changed, hence we do a COMP (DOS file compare). The COMP command produces silly prompts, so we're piping it to a null device.

In lines 5 & 6, the DOS Errorlevel command is a very old facility that lets us work out what the outcome of the COMP command was. You need to always check for the highest errorlevel first. (ie: 1 is higher than 0).

All of the echo statements are irrelevant but useful if you need to see what's going on during testing. To test, add the word pause on a line of its own at the very end - but don't forget to remove it when you start scheduling it.

Scheduling the Process

So, we now have a batch file that will copy our file from the domino server to the file server. The next task is to schedule the batch file to run at regular intervals - and with correct rights. Here's how;

You should do this on the target server (not the domino server), unless your batch file is changed to work in the opposite direction.

1. Start the scheduled task wizard; Start, Control Panel, Scheduled Tasks, then click Add Scheduled Task
   
   
2. At the introduction, click Next.
   
   
3. Browse and Select your application (the batch file)
   
   
4. Give your Task a name
   
   
5. Select the time to run as Daily (we really want to run every half-hour) but we can't do that in this section.
   
   
6. Choose a time (6.00am is good),
   
   
7. Choose Weekdays and set the Start Date to today.
   
   
8. Click Next
   
   
9. Put an appropriate domain/directory user name and password (with rights to run as a service) in, then click finish.

You now have a scheduled agent which will run once daily. If something goes wrong with the password, then only the copy script will fail - you can still copy manually. Plus, the extent of the security compromise is limited to the batch file (which hopefully you've stored somewhere where only IT people can change it).

Modifying the Scheduled Task

To modify the scheduled task, simply click Start, Control Panel, Scheduled Tasks, then locate your task, right mouse click on it and choose properties.

You'll notice an advanced button. Click it and make some changes.

In particular, you might want to click the [X] Repeat Task checkbox and fill in a regular repeat interval (30 minutes) and an Until time.

I'm not sure what happens if you don't have an until time but I have visions of a new agent starting every day (so that you have 5 by Friday). I'd recommend that you put one in. If your task is supposed to run 24x7, you might repeat until 11.30pm and then kick off a new task at 12.00am.

So; that's it! You can now run your task whenever you want. You might find that the newly created task doesn't kick in until midnight - if so, check your date, Windows has an annoying habit of putting tomorrow's date in when you select daily task.

If you're after more comprehensive info on scheduler, you might want to check out this site;

http://www.iopus.com/guides/winscheduler.htm