I tried configuring VSS 2005 to enable the LAN 'booster' service but it didn't seem to have much effect. Putting network monitor on the line it looks as though Visual Studio 2005 is still using SMB to communicate with the VSS Server.
Is there some configuration I need to do on the client end to get this working The Visual SourceSafe help file doesn't say too much more than that the booster service is optional. I took that to mean I didn't need to configure it at the Visual Studio plug-in end but perhaps I'm wrong
Should the LAN Booster Service work in Beta 2?
Hot Topic
- C# 3.0 uninstall
- Change the Sorting order of Report
- Visual Studio 2005 Will Not Install
- Error:"The Assembly could not be found or could not be loaded" .The problem is at even click to the word document
- VS 2005 Editions
- New button in navigation pane in Oulook 2003
- Network Not Found and/or Invalid Handle
- Avoiding security alert in Outlook while accessing Contacts in VSTO 2005
- What the method EntitySet.RemoveAt is for?
- LogonException When Exporting Pushed Data to PDF
Visual Studio
- ContextMenu and Data?
- Custom UIElementCollection and data binding
- How to register an Add-in
- Office 2003 and Office XP.
- time series plot for Xrystal reports
- How to set ReportPath
- Interesting DLinq questions
- Any good Books on using WCF in SOA
- Getting Started with Interactive Designer (blur with XAML & CS code)
- Tell VSS to ignore a file - basically like .ignore in CVS
Should the LAN Booster Service work in Beta 2?
Millen Tomov
The value 0x6BA is 1722 decimal and the Command Window command net helpmsg 1722 shows the error message: The RPC server is unavailable.
My guess would be that your Visual Studio client tried to open an RPC connection to the VSS helper service on 192.168.10.212 and that failed for some reason. Figuring out what that reason is can be challenging.
You could look in the event log in the hopes that something more informative appears there. You could check some of the basics - check that a PING 192.168.10.212 works and that telnet 192.168.10.212 135 works (this checks you can open to the RPC endpoint mapper). You could also check that the LAN helper service is running on 192.168.10.212
Perhaps the best approach would be to install the SMS NETMON (or some other network monitor that understands RPC) on your client and monitor the traffic to and from it. You should be able to see some RPC traffic between your client and 192.168.10.212 and if you are lucky you can find a more detailed RPC error code in one of the responses from the VSS system.
Event666
Teodulfo
There isn't any special configuration on the client side (there may be some configuration on the server side though). On the client side, just make sure that VSS database you're accessing is referenced through a file share on a remote machine. The LAN service is not used for databases on the local machine.
Do you see any RPC communication between client and server, or only SMB
You can check the Output window in VisualStudio, if the service is not accessed with remote databases you will see there a message like "Unable to use SourceSafe LAN service, performance of SourceSafe operations will not be optimal.". If that's the case, you can use on the client machine DebugView from SysInternals (http://www.sysinternals.com/ntw2k/freeware/debugview.shtml) and look for error codes dumped by SSService process, they may be helpful in identifying the problem.
On the server side, make sure the firewall allows RPC communication. Also, make sure that your RPC policies do not restrict anonymous RPC calls using callbacks to perform authentication. Check Application EventLog, the service will write an entry there on startup if it detects it cannot be accessed for one of these reasons.
(If you're on XPSP2 the service normally prompts to adds itself to the firewall's exceptions list and prompts to change the RPC policy when the RPC service is enabled)
Ankola
Sorry this is so late, work got in the way.
Yes. I restored an archive of one of our production databases as my test database
It didn't have that line.
Adding seems to have helped - I now see MSRPC traffic on the line monitor and if I disable the Helper Service I get a message in my Source Control Output window indicating that the helper service isn't being used .
GrandmaGG
Service is running.
My point is the error message is pretty much useless for helping resolving problems and it seems that a little effort for a more informative error would be useful. I may add one to feedback center to push that a little more if one doesn't already exist
Also - any official statement on whether the booster will work with VS2003 when using the VSS 2005
Thx
Dave
philagain157
On the other hand, using the Internet plug-in cross-country the GET only takes about one minute ten seconds. Not as good as local, but a heck of a lot better than thirteen minutes.
I think perhaps my expectations were all wrong - I was expecting the regular plug-in plus booster service to be as fast as the Internet plug-in
Just SMB. If I open an existing project and then filter the netmon output for MSRPC I see eight packets: bind to srvsvc and response; call to srvsvc:NetrShareGetInfo and response; bind to wkssvcand response; call to srvsvc NetrGetShareInfo and response.
I'm afraid I don't see anything like that. Just "Operation started at ..." and "Operation completed successfully at ..."
There's nothing obvious.
There are some 105 and 108 entries from SSService. I had to hand build the Eventlog registry keys for SSService to define the EventMessageFile before event viewer would interpret them but they are just Service Started and Service Stopped indications. I'll bug that.
When the SSService service startes, the System event log does show Side-by-Side errors indicating that the resolve for the partial assembly Microsoft.VC80.MFCLOC failed - referenced assembly is not installed on your system.
hoogli
[2840] VSS RPC Service call failed, server: 192.168.10.212, err: 06ba
I sure hope a better error message gets in the RTM other than "Unable to use LAN, performance won't be optimial"
Arun C
> So the actual file 'get' is still SMB
Yes, the 'get' itself is still SMB. However, the detection of which files are newer on server should be faster. For instance, doing a Get when most or all of the files are up-to-date (a "Get-no-op") should be much faster with the service on.
In that case we use the service to detect there are no newer files, and we won't do a Get for the files that are not changed. Probably in the 'no-op' case there won't be any SMB activity.
> On the other hand, using the Internet plug-in cross-country the GET only takes about one minute ten seconds. Not as good as local, but a heck of a lot better than thirteen minutes.
On low-latency networks (like dsl, cross-country), VSS Internet will be better to use. Note however that VSS Internet doesn't support delete and renames propagation and synchronization like the main VSS plugin does.
>When the SSService service startes, the System event log does show Side-by-Side errors indicating that the resolve for the partial assembly Microsoft.VC80.MFCLOC failed - referenced assembly is not installed on your system.
We just got a bug on this, and we are investigating the fix.
> There are some 105 and 108 entries from SSService. I had to hand build the Eventlog registry keys for SSService to define the EventMessageFile before event viewer would interpret them but they are just Service Started and Service Stopped indications. I'll bug that.
I just reproduced this with beta2.50215.44. The service must be stopped and restarted at least once for this to repro. Can you please open a bug for this, please
> Just SMB.
> I'm afraid I don't see anything like that. Just "Operation started at ..." and "Operation completed successfully at ..."
Hm... This looks like VisualStudio does't encounter failures on accessing the service, but is not accessing it. Was by any chance the database you're trying to access created with a previous version of VSS6
With Beta2 builds, VisualStudio doesn't even try to access the service on databases created with VSS6. The reason is the lack of a line like "UseHelperService = Yes" in srcsafe.ini. Beta2 builds interepreted the lack of this line as "don't use helper service with this database".
This behavior has been changed in more recent RTM builds.
Can you verify if your srcsafe.ini file contains a line "UseHelperService = Yes"
If not, add this line and VisualStudio should start using the service after a restart.
Thanks,
Alin
BamaGal
There's a world of difference between not being able to open the endpoint mapper port (because the host is down or communication is blocked by a firewall for example) and opening the endpoint mapper connection successfully but finding the endpoint requested is not registered (because the LAN Service isn't running for example).
I woul imagine that information is available somewhere in the bowels of the protocol stack but it is getting turned into RPC_S_SERVER_UNAVAILABLE.
It's like trapping an exception in a try-catch block and then throwing a generic "Exception happened" exception :(
I'm not really trying to whine here, Nor am I trying to pick on you when all you did was try to help by responding to this thread.
I'm just trying to raise the issue that the more diagnostic data that's made available the more likely it is that people are going to solve problems for themselves or with the help of the community and without a service call to Microsoft or the frustration of giving up.
Andrew Babiec
I'm glad to hear the LAN service is working for you now.
In beta2 we experienced some long connection delays with certain older VSS databases, and this is why we had that UseHelperService = No by default when the line in ini files was missing. After Beta2 was shipped we moved the service detection on a background thread and we overturned the decision about not using the service with databases created with VSS 6.0. With the RTM version you won't need the line in the srcsafe.ini.
As for the effect of using the LAN service, I'd expect to have shorter times on all scci operation, and a bigger effect during get_no_op. Ymmv.
Thanks,
Alin
Vincent Rainardi
I doubt the message displayed by VS in the output window will change in RTM. It is just a warning that performance may be better by using the LAN service. The message is not necessarily an error.
Frank is right, the 06ba error is RPC_S_SERVER_UNAVAILABLE.
There are many reasons why this error can be returned, but the idea is that VisualStudio cannot contact the VSS RPC server on the machine with the IP 192.168.10.212. While this may be because RPC communication is blocked, it may also be because you or the admin decided not to enable the LAN service on the VSS server.
Make sure you have enabled the VSS LAN Booster service on the machine with the IP 192.168.10.212 (I believe that's the machine hosting the VSS database). Use SSAdmin / Server / Configure / LAN Service dialog for this.
Use "sc status ssservice" to check whether the service is running.
Also, make sure you don't run a firewall program that blocks RPC communication or SSService.exe in particular. Also, check the Applications event log on the 192.168.10.212 machine if you have any warning entries written by the service when the service starts.
Alin