Article ID: 175586
Article Last Modified on 5/2/2006
APPLIES TO
- Microsoft Visual InterDev 1.0 Standard Edition
This article was previously published under Q175586
SYMPTOMS
There are several symptoms of this problem, two of the most common are listed below:
- When a user checks out a file from a Visual InterDev project that has been placed under source control, the SourceSafe Explorer tool shows that the file has been checked out by the IUSR_machinename account.
- Multiple users will be able to check out the same file at the same time. Whoever checks in the file first will succeed, but other users will not be able to check in the file.
CAUSE
These problem are all caused by files being checked in and out of Visual SourceSafe "anonymously." When Visual InterDev places a project under source control, it works completely through the FrontPage server extension as a kind of "proxy," which then works with SourceSafe to check in and out the appropriate files.
Correcting this problem revolves around ensuring that the anonymous account cannot author or administer the Web.
RESOLUTION
To prevent the anonymous account to author and administrate a Web, ensure the following:
- The Web server must be using an NTFS file partition. FrontPage server extensions and Visual SourceSafe rely on NTFS to set file permissions to control who can check in and out specific files. On a FAT partition, the anonymous account (by default, IUSR_<machinename>) will always succeed when checking out files.
- Visual InterDev's Web Permissions may not be correctly configured. In Visual InterDev, select "Web Permissions from the Project menu. If the anonymous account appears on the Users tab, or if the anonymous account belongs to any group on the Groups tab with either Author or Administer rights, then the anonymous account will be used to check in/out files.
While the Everyone account is often in the Groups tab by default, it should NEVER be left in. There is never a time that files should be allowed to be checked out anonymously, as multiple anonymous check outs will cause more serious errors. This configuration is usually the result of the hard disk being originally formatted as a FAT drive, and later was converted to NTFS.
The Visual InterDev documentation for Visual SourceSafe also mentions having the IUSR account entered in the Visual SourceSafe administration tool so that you can check in and out files anonymously. While this is technically accurate, it is a poor practice in most any environment for the same reasons stated above.
The best practice for configuring Web permissions is to first set the permissions on the root Web, and then have projects use either the same permissions as the root Web, or set unique permissions when needed.
Setting the Web Permissions for the Root Project
If the root Web has never been accessed before, simply select New from the File menu and select a new Web Project. Select the appropriate server, and when you are prompted with the list of existing Webs, select the <Root Web>. Once the Root Web is opened in the Project Workspace window, you can choose the Project/Web Permissions menu item and specify users and groups.
If you select Web Permissions in a normal project (not the root Web) there will be three tabs: settings, users, and groups. If you change the option button from the default, you will lock out the tabs and not be able to switch between them until you click the 'Apply' button. This is because changes need to be enacted on the Web project before the user and group tabs can be displayed.
Note what user and group NT accounts are listed for the Root Web by default.
The Everyone account that is added to the root Web by default must be removed! Having the Everyone group allowed access will cause files to be checked out on the Web server by the IUSER_<machinename> account. This also allows multiple individuals to check out the same file and corrupts the Visual SourceSafe database, completely obviating the very reasons for implementing source control.
Note that for each user or group that is added to access list, you must choose between three levels of authority:
- Browse--Useful if the 'Only registered users have browse access' is selected.
- Author and browse--This user can now add, delete and edit content, as well as browse.
- Administer--This user can create and delete Web projects, and change permissions.
Users
Add specific users to the access list. This is the preferred method. All users should be entered explicitly in this dialog box.
Groups
These are group names that are defined in the NT User Manager for Domains tool. For best results, ensure that none of your groups contain the IUSR_machinename account or any account that is anonymous by nature. If the groups you use consists of explicit NT user accounts, then they will work fine. A common technique would be to create an NT group called "WebAuthors," and assign users to this group in the NT User Manager. This group can be added in Visual InterDev and given appropriate rights.
Changing Specific Web Project Permissions
Once the root Web has been correctly setup, and the Everyone account has been removed, it is possible to successfully setup the Web permissions for specific projects. The simplest approach is to set a project under source control, and in Web Permission, select the "Use same permissions as root Web" button. If it is necessary to give the project unique permissions, select the alternate button, click Apply to unlock the tabs, and follow the same steps as for the root Web.
STATUS
This behavior is by design.
REFERENCES
For the latest Knowledge Base articles and other support information on Visual InterDev and Active Server Pages, see the following page on the Microsoft Technical Support site:
Keywords: kbwebserver kbprb KB175586
