MORE INFORMATION
Before going into the detailed steps necessary to enable the integration,
this article will explore the following factors:
- How FrontPage and Visual InterDev Work with Visual SourceSafe.
- Which Visual SourceSafe Database Is Used?
- Local vs. Remote Visual SourceSafe Database.
- The Anonymous User.
How FrontPage and Visual InterDev Work with Visual SourceSafe
The FrontPage Server Extensions use OLE automation to connect to and
interact with Visual SourceSafe.
All Visual SourceSafe operations are performed by FrontPage Server
Extensions on the Web server itself, not client machines. The Web server
can be Internet Information Server (IIS) or Personal Web Server using the
DCOM extensions. This article relates mainly to IIS.
Which Visual SourceSafe Database Is Used?
FrontPage Server Extensions must find a Srcsafe.ini file to perform Visual
SourceSafe operations through OLE automation.
While this key points to the Ssscc.dll in the VSS\Win32 directory,
FrontPage Server Extensions will use the SrcSafe.ini in the VSS directory.
- Visual SourceSafe 6.0 normally uses the SrcSafe.ini in the Web server's
installation of Visual SourceSafe. If there multiple VSS installations,
it will use the one most recently installed.
Local vs. Remote Visual SourceSafe Database
A local database is one that is on the same machine as the Web server and
is accessed through local paths only. A remote database is one that either
resides on a separate computer, or on the same one as the Web server, but
it is accessed as if it were a network location.
To illustrate this, if you are using Visual SourceSafe 5.0 and the local
path to Ssscc.dll is as follows:
C:\vss\win32\ssscc.dll
But the registry points to one of the following:
\\mymachine\vss_share\win32\ssscc.dll
X:\vss\win32\ssscc.dll
Even though this may be the same physical location on the Web server
computer, if it is accessed as a UNC path or a logical drive, it is
considered a remote database.
You can also use the Data_Path ini variable in the Srcsafe.ini file to
point to remote data. By default the setting is as follows:
Data_Path = data
However, users can modify this to point to different locations.
The Anonymous User
In the steps necessary to enable integration, several references are made
to the Anonymous user. These steps should only be when "Allow Anonymous" is
enabled in the IIS Web Service Properties.
- For FP, the Anonymous user always has to be configured correctly.
- In Visual InterDev, if the Anonymous user has either Browse and Author,
or Browse Author and Administer permissions to the web, Visual InterDev
will also require the Anonymous user to be configured correctly, but the
more appropriate resolution is to give the Anonymous user either Browse
only, or no permissions to the Web.
The following section describes the steps you need to perform to enable the
integration.
Steps Necessary with both Local and Remote Databases
There are four components that you must configure correctly:
- The Visual SourceSafe Installation on the Web Server
- Permissions to the Visual SourceSafe Directory Structure
- Accounts in the Visual SourceSafe Administrator
- The Anonymous Account (if applicable)
The VSS Installation on the Web Server:
To enable OLE automation with VSS, the file Ssapi.dll must be registered
(that is, in the Windows Registry) on the Web server. While it is possible
to do this manually using Regsvr32.exe, the preferred method is to install
either the VSS server or client components on the Web server. With VSS5
select Custom setup, and make sure that the Enable Visual SourceSafe
Integration check box is selected.
Permissions to the Visual SourceSafe Directory Structure:
To view Directory permissions, right-click the Directory in the Windows NT
Explorer, click Properties, click the Security tab, and then click
Permissions. To view Share permissions, right-click the shared Directory in
the Windows NT Explorer, click Properties, click the Sharing tab, and then
click Permissions.
Assign CHANGE permissions to all Visual SourceSafe logon accounts for all
files and subdirectories under the Visual SourceSafe server installation
directory.
It is assumed that the Administrators and System accounts will be granted
Full Control to the entire Visual SourceSafe directory hierarchy. Although
tighter file restrictions might be possible, full Visual SourceSafe
functionality might be jeopardized by tighter restriction.
Accounts in the Visual SourceSafe Administrator:
Add the actual FrontPage or Visual InterDev user(s) (password optional).
Under the Tools menu, click Options, click the General tab, and make sure
that "Use network name for automatic user log in" is selected.
The Anonymous Account (if applicable):
Do the following on the computer running IIS:
- Ensure that the anonymous account has Log On Locally privileges. Use the
following steps to do this:
a. Run the User Manager For Domains.
b. On the Web server machine select "User Rights..." from the Policies
menu.
c. From the right drop-down list, select "Log on locally." Make sure
that the anonymous account is listed either individually or as a member
of one of the groups.
- Check that that the anonymous account has the same password in both IIS
Service Manager and User Manager For Domains. You might have to re-enter
the password in both these places. The following are two potential
pitfalls:
a. In User Manager For Domains the password always appears padded out to
14 characters. This can be confusing if you have entered a shorter
password.
b. After changing the password in IIS you should stop and restart the
service to clear out any password caching.
- Make sure that the anonymous account can log on automatically to the Web
server. In User Manager For Domains make sure that the "User Must Change
Password at Next Logon" and "Account Disabled" check boxes are not
selected.
NOTE: If you are uncertain about what your computer's anonymous user
should be, go to the IIS configuration utility, and look in the
properties for the WWW service.
- In the Visual SourceSafe admin, add the anonymous account as a user with
no password.
- Make sure that the Anonymous account has permissions to the Visual
SourceSafe directories as in the "Permissions to the VSS Directory
Structure" section of this article.
Additional Steps Necessary for Remote Databases
- On the computer running IIS, set the correct properties for the WWW
service in IIS. In the Service Properties for the WWW service, the three
check boxes for Password Authentication should appear as follows:
Allow Anonymous - Optional.
Basic (Clear Text) - selected.
Windows NT Challenge/Response - not selected.
Windows NT Challenge/Response is also referred to as NTLM. Because this
setting is not selected, users have to enter their user name and domain
password when they open a Web. Use the format "domainname\username" for
the user's name when working with multiple domains.
- If Allow Anonymous is enabled, do the following on the computer with the
Visual SourceSafe Database:
a. In User Manager For Domains, add the Web server's anonymous account.
For example, if the anonymous account on the Web server is IUSR_WEBSRV,
add that user as a local account.
b. Give IUSR_WEBSRV the same password as it has on the Web server.
c. Make sure that IUSR_WEBSRV has logon locally permissions.
- Directory and share permissions to the Visual SourceSafe directory
structure must be set correctly as the "Permissions to the VSS Directory
Structure" section of this article.
Troubleshooting
NOTE: If the server computer is running Windows 95, make sure that a user
remains logged onto Window 95. Users often leave the server at the login
prompt. The integration between Visual SourceSafe and Visual InterDev will
not work when there is no one logged onto the server.
The Windows NT Event Viewer on the IIS server often contains information
that can help locate the cause of a problem if integration is not working.
These log errors usually come in pairs, the later (topmost) of which
usually contains an error number and the one below it a short description
of the error. Double-click a log entry to view its details.
NOTE: Visual InterDev usually reports errors encountered in an error
message, whereas FrontPage suppresses the errors. To ensure that FrontPage Server Extensions writes errors to the Windows NT event log, refer to:
191289
How To Enable Event Error Logging for FrontPage 98 and SourceSafe
The errors might differ depending on exactly how the components are
configured. Following is a list of possible errors might that appear in the
Application Log and their causes:
- Error: Source Control System failure: File "Srcsafe.ini" not found.
Cause: Visual SourceSafe integration is not enabled. In the case of
Visual SourceSafe 5.0 this usually happens when there is no
SCCServerPath in the registry of the Web server computer.
- Error: Source Control System failure: User "" not found.
Cause: "Use Network name for automatic login is not selected in the
Visual SourceSafe Administrator.
- Error: Source Control System failure: User <username> not found.
Cause: The user <username> has not been added to the Visual SourceSafe
database.
- Error: Source Control System failure: Could not find VSS resource DLL
Cause: The anonymous or user accounts do not have the correct NTFS file
permissions.
- Error: Source Control System failure: Access to file "<path>
\srcsafe.ini" denied.
Cause: IIS and the Visual SourceSafe database are on different computers
and NTLM is enabled.
- Error: Source Control System failure: Access to file "<path> \um.dat "
denied.
Cause: IIS and the Visual SourceSafe database are on different computers
and NTLM is enabled.
- Error: Source Control System failure: Invalid handle.
Cause: IIS and the Visual SourceSafe database are on different computers
and the anonymous account has a different password on the two computers,
or does not have Log on locally permissions on the Visual SourceSafe
computer.
- Error: [ASCII 147]The SourceSafe database path does not exist. Please select
another database"
Cause: User has insufficient permissions to the VSS directory. For
troubleshooting purposes give all users Full control to the VSS
directories, then selectively start restricting access.
Errors that appear in the System Log:
- Error: The server was unable to logon the Windows NT account <anonymous
user account> due to the following error: unknown user name or
bad password.
Cause: On the IIS computer, the anonymous account either does not have
Log on locally permissions, or the account's password in IIS and User
Manager differ.
- Error: The server was unable to logon the Windows NT account <anonymous
user account> due to the following error: unknown user name or
bad password.
Cause: The anonymous user account has been disabled in User Manager.
REFERENCES
General Integration Information
For general information on Visual InterDev integration, see the online
documentation in the User's Guide, Authoring Web Content, Using Visual
SourceSafe With your Web.
Troubleshooting
For more information about troubleshooting FrontPage or Visual InterDev integration, click the following article number to view the article in the Microsoft Knowledge Base:
160766
VSS Source Control Project box does not appear in FrontPage 97
IIS Security and the Anonymous Account
For general information on IIS security and the anonymous account, see
Chapter 5 of the online documentation for IIS (Inetdocs.htm).
For more information about developing Web-based solutions for Microsoft Internet Explorer, visit the following Microsoft Web sites:
For more information about directory and share permissions, click the following article number to view the article in the Microsoft Knowledge Base:
131022
Required network rights for the SourceSafe directories