DCOM Error resolved and replicated... SourceOffsite 3.5.2

If you are having a problem using SourceOffSite, post a message here.

Moderator: SourceGear

Post Reply
StamfordRob
Posts: 2
Joined: Thu Feb 26, 2004 9:55 am

DCOM Error resolved and replicated... SourceOffsite 3.5.2

Post by StamfordRob » Thu Feb 26, 2004 10:04 am

:D :D :D

Hi Linda..

after all the answers and trials that i have received from your company we still had no luck resolving the DCOM error. that left me with no other option than to resolve this issue.. after mulitple builds and tests we have been able to replicate this error and find its minimum requirements for resolution.

it seems that your software (SourceOffsite Classic 3.5.2) cannot be locked down to users. all of the clients that you told me that have this issue must have been trying to secure the folders and shares. the dcom error arises when you remove 'Everyone' from the folders of both sourcesafe and sourceoffsite... we found that no matter how the system was built that it was the permissions on the folders that give the error.

we found that the ONLY user that was needed on both folders was the 'SYSTEM' user. your software interacts with this user against the DCOM. With that user in place with a minumum permission of 'Modify' everything is fine. I did not have to change users on the service.. nor did i have to add or change users on the MDM...

just thought that i would pass that along to you and the support group. something like that should have been tested for and known by support.

r



Linda Bauer <Linda@sourcegear.com>
02/18/2004 02:16 PM


cc
support@sourcegear.com
Subject
Re: DCOM error







Hi, Rob,

It's possible for the ssapi.dll not to be properly registered if VSS was
installed after SOS on the SOS Server machine. Also if VSS was copied and
not installed from disk. There may be more than one ssapi.dll on a machine
and the wrong one might be registered.

I did some investigating about the DCOM error, but the person I consulted
with need to know the exact error message. Could you provide that, or has
SOS already been moved from that machine?

Thanks,

Linda Bauer
SourceGear
Technical Support

At 02:47 PM 2/17/2004, you wrote:

>i have the ssapi.dll in the win32 folder.. how could that not have been
>installed or registered??
>
>
>
>
>Linda Bauer <Linda@sourcegear.com>
>
>02/17/2004 03:37 PM
>To
>
>cc
>support@sourcegear.com
>Subject
>Re: DCOM error
>
>
>
>
>Hi, Rob,
>
>I don't have more info on the DCOM error at this time, but I'll check into it.
>
>Regarding the other error:
>
>Something is apparently not quite right with the VSS installation on the
>server machine hosting the SOS Server.
>
>The SOS Server uses Microsoft's Automation layer to communicate with
>the VSS database so a copy of the VSS Client component must be installed
>on the server machine. Installing the VSS Client should install the
>necessary VSS APIs.
>
>Please verify the following:
>
> 1) Was the VSS Client installed on the SOS Server machine?
>
> 2) Was it installed from CD?
>
>If VSS has not been installed yet on that server machine, we suggest doing
>so. After rebooting the server machine, you should be able to connect and
>download the project tree successfully with the SOS Client.
>
>If VSS files were moved from one installation to another, then the problem is
>probably related to the VSS Automation component not being properly
>registered in the System Registry. In this case, manually registering the
>SourceSafe Automation component (ssapi.dll) should resolve the problem.
>The steps to manually register the Automation component are outlined below.
>
>---------------------------------------------------------
>Manually registering the Automation component
>---------------------------------------------------------
>
>1. Using regEdit, do a find on ssapi.dll and delete all keys pertaining to
> ssapi.dll in the System Registry.
> (This must be done in order for the following steps to work.)
>
>2. Bring up the Command Prompt.
>
>3. Change directories to the SourceSafe win32 folder.
> The default path is similar to C:\Program Files\...\VSS\win32
>
>4. Run the following: regsvr32 ssapi.dll
>
>
>This will register the Automation component for SourceSafe 6.0 (or 5.0).
>
>The SOS Server must be re-started after completing the above steps.
>
>
>Linda Bauer
>SourceGear
>Technical Support
>
>At 10:18 AM 2/17/2004, you wrote:
>
> >Hi Linda
> >
> >these did not correct the issue for me.. and i am a liitle reluctant to
> >delete the classID.. can you tell me a little more on that ..
> >
> >also.. i am trying to reuse the old sourceoffsite server and we receive an
> >error at connection ' The server is unable to locate the SourceSafe
> >automation component." Can you get me around this??
> >
> >thanks..
> >r
> >
> >
> >Linda Bauer <Linda@sourcegear.com>
> >
> >02/17/2004 10:17 AM
> >To
> >
> >cc
> >support@sourcegear.com
> >Subject
> >DCOM error
> >
> >
> >
> >
> >Hi, Rob,
> >
> >Thanks for contacting Technical Support. Here's the information about SOS
> >and DCOM:
> >
> >The SOS Server is not a DCOM Server ... nor does it use DCOM.
> >
> >Is the SOS Server on the same machine as the VSS database?
> >
> >If so, I would suggest you try changing the account running the Server
> >service. The Server service can be run under any domain account that
> >has full access to the machine/drive containing the VSS database
> >installation.
> >
> >You may also want to search through your System Registry on the classID
> >listed in the Event log. This search may point to the DCOM Server that is
> >having problems.
> >
> >The following Microsoft Knowledge Base article contains information which
> >should help in getting rid of this error:
> >
> >http://support.microsoft.com/default.as ... icrosoft.c
> om:80/support/kb/articles/Q290/3/98.ASP&NoWebContent=1
> >
> >One of our other customers had the same error and the classID pointed to
> >the debug manager. The problem was solved by removing the debug
> >manager. There seems to be a link with starting the Server service and
> >seeing this error. We just don't know what that link could be. The SOS
> >Server should not be accessing the MDM Utilities.
> >
> >--Also, do a search to verify that msjava.dll is on the SOS Server machine.
> >SOS is written in java and needs that .dll to run.
> >
> >Please let me know if you have further questions.
> >
> >Linda Bauer
> >SourceGear
> >Technical Support
> >
>

Linda Bauer
SourceGear
Technical Support

visit our support forum at
http://support.sourcegear.com

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Mon Mar 01, 2004 11:24 am

Could you provide a few more details? I'd like to cause the DCOM error on my own machine by replicating the environment you describe.

When the DCOM error happens, what users/permissions are set for the SOS Server installation directory and for the VSS directory where the scrsafe.ini file resides?

Then what users/permissions cause the DCOM error to go away?

What account is being used by the SOS Server Service? Only the System Account?

This may not work for users that have the VSS database on another machine since usually the System account (a local account) does not have access to the machine where the VSS database is hosted.
Linda Bauer
SourceGear
Technical Support Manager

Post Reply