If Open file agent is installed, it causes the Geopak application...

[Guest_imported]

Hi,
There is an civil engineering application called Geopak which is installed in Windows 2000 pro. When the ARCserve Backup Agent for Open files is installed, it stops the users from connecting to Geopak simultaneously. When the OFA is uninstalled, everything is OK. Why is this?

 

[ARCserveGuru]

what option are you using during the backup job?

If your using Lock mode, then the users wont be able to connect, if your using "use deny none if deny write fails" then it should be cool.

If you are using deny none if deny write fails and it's happening then it might be something else.

guru

 

[ramdaus]

But this happens with the BAOF agent. No backups are being done. If BAOF is installed, GEOPAK users won't be able to access simultaneously, if BAOF is removed, everything is fine. There is no backup option involved here. Thank you for the response, awaiting more...

 

[ARCserveGuru]

This option is the way your computer manages the conflict.

Regardless of BAOF


guru

 

[NIS2002]

I have a similar problem with a health application within the NHS. Just to re-enforce the issue. The failure to allow multiple client connectivity to a server file happens when the back-up processes are idle. Furthermore it appears to only affect Win 2000 clients Win 95/98 appear to be unaffected as long as there are no win 2000 clients using the file.

 

[ARCserveGuru]

Try getting the job engine to log on using the arcserve system account, preferrably a Domain Admin account.

Let me know how this goes.

guru

 

[NIS2002]

Thanks ArcserveGuru.

Your suggestion above has made no difference. I need to stress here that this is occuring simply by installing the OFA I have not got to the stage of configuring it to do anything. By using uninstall wizard the problem goes away.

Incidentally the app that is having difficulties is an Omnis7 library file. A text file within the same directory allows multiple simultaneuos connections without complaint.

Best regards.

 

[dmarton1]

Hi there

I just had the same behavior today when I installed ARCserve 2000 on a Windows 2000 Advanced Server machine where a few dozen users where sitting on (was a fileserver). Just right after I installed the Backup Agent Open Files, most of the users got instantly disconnected and new users trying to connect to their shares on this servers could not connect (so I was in a bad, bad situation).

I took a short look into the system event log and found a huge amount of the same message saying something like: "the value for the parameter "irpstacksize" is set to low to serve a local device".

Well I had just a similar problem with installing CA SurviveIT 2000 on two Windows NT servers and also InoculateIT 6.0 Workgroup Edition on a Windows NT server (no connections possible any more). So today I tried the same thing as I did in the past with my SurviveIT and InoculateIT problem experience:

- start the regedt32 program
- switch to the window HKEY_LOCAL_MACHINE
- open SYSTEM / CurrentControlSet / Services / LANManserver
- select the "Parameter" key on the left side and take a look at the values on the right pane side
- you most likely will find a value "IRPstackSize" with a value of 13 (decimal) or any other value
- Rename (or delete and redefine) the Key to the correct syntax "IRPStackSize" (Capital letter for the beginning of "Stack&quot
- Set a value of say 24 (my guess-value on todays installation)
- Close regedt32
- Stop the service "Server" (this will automatically stop "Distributed File System", "Computer Browser" and "ARCserve Discovery Service" as well other possible, depending services.
- Restart the service "Server" (I think this will autostart the "Computer Browser", but you still have to start "Distributed File System" and "ARCserve Discovery Service" manually.
- tell the users to try to connect to the server again
- everything should be "normal" again

I think, some of CA's setup routines are putting the "IRPStackSize" into the LANManserver parameters list. I think of this, because before installing CA software this key does not exist yet in the parameter list. I read in MS Knowledgebase that the default value of this key would be 11 (although not visible in the registry, the key exists in the "background" and has a value set to 11). You must define this key manually and assign the value, to override the default value (11). Why CA's setup is defining this key and is setting it to 6 in SurviveIT 2000, or 4 in InoculateIT Workgroup Edition - I really have no clue about. I just know, that no other setup program I know is doing this to me ... And: CA's setup is not doing this always (just to confuse totally).

So remember to check the IRPStackSize key in the registry whenever again should installing any CA software disconnect your users / applications from the server you are installing the software to.

Please give me a feedback, if this workaround helped. Sorry for the long text, but I like to hit my keyboard (softkeys - hehe).

Kindest regards

david a. marton, restorage gmbh - switzerland

 

[ARCserveGuru]

David, sounds like your right about the stack size. did this resolve your problem on the arcserve2000 server as well as the surviveIT? (from above I know sruviveIT worked for you but I think you fail to mention if it worked for the OFA.

Thanks,

guru

 

[dmarton1]

Hi there

sorry, yes it did work. I have done the following steps (as mentioned before):

- start the regedt32 program
- switch to the window HKEY_LOCAL_MACHINE
- open SYSTEM / CurrentControlSet / Services / LANManserver
- select the "Parameter" key on the left side and take a look at the values on the right pane side
- you most likely will find a value "IRPstackSize" with a value of 13 (decimal) or any other value
- Rename (or delete and redefine) the Key to the correct syntax "IRPStackSize" (Capital letter for the beginning of "Stack&quot
- Set a value of say 24 (my guess-value on todays installation)
- Close regedt32
- Stop the service "Server" (this will automatically stop "Distributed File System", "Computer Browser" and "ARCserve Discovery Service" as well other possible, depending services.
- Restart the service "Server" (I think this will autostart the "Computer Browser", but you still have to start "Distributed File System" and "ARCserve Discovery Service" manually.
- tell the users to try to connect to the server again
- everything should be "normal" again

kindest regards

david a. marton, restorage gmbh - switzerland

 

[jybi]

Hi,

We have a similar problem with BAOF.
It seems to be a conflict between BAOF and DOCSFusion from Hummingbird (DMS).
ARcserve server is running on the same machine as Fusion (machine 1).
BAOF Agent is installed on a remote server (machine 2) on which Fusion copies pdf files.
With BAOF installed on machine 2 (but not running), all files copied by Fusion are corrupted after a shutdown / reboot of machine.
All servers are installed in W2000.
Servers are Compaq DL380 with hardware RAID 1 (machine 2) and RAID 5 (machine 2) with a Smart CARD.

Could someone help us?

Best regards,

JYBI

 

[BillDaly]

Here's the real solution:

Look up QO36927 (Dated 5 APR 2003) on the CA support site.

It provides a new OFANT.SYS (Open File Agent) driver that works in both Windows 2000 and 2003 and fixes the "multiple users can't access files concurrently" issues that are so troublesome in both the ArcServe OFA and SurviveIT/HAM (which also includes the OFA).

We were having the same issues with AutoCAD 2004 Land Desktop, Bentley Microstation J, Timberline Medallion, and Axium Protrax. Stopping the OFA service had no effect. Only renaming the OFANT.SYS (or uninstalling SurviveIT and OFA, same effect) and rebooting would fix the problem. The new driver also works, with the added benefit of being able to use the software.

When you replace the file, you will have to reboot. Stopping and starting services isn't sufficient.

Note that QO36927 is not listed under the patches for SurviveIT/HAM, but it seems to work with it.

 

[RedstoneTek]

Microsoft KB article 822219 explains what is happening.