We would not have networks, or our jobs, if organizations did not find it valuable to provide access to information and resources stored on one computer to users of another computer. Creating a shared folder to provide such access is therefore among the most fundamental tasks for any network administrator. Windows Server 2003 shared folders are managed with the Shared Folders snap-in.
Sharing a Folder
Sharing a folder configures the File And Printer Sharing For Microsoft Networks service (also known as the Server service) to allow network connections to that folder and its subfolders by clients running the Client For Microsoft Networks (also known as the Workstation service). You certainly have shared a folder using Windows Explorer by right-clicking a folder, choosing Sharing And Security, and selecting Share This Folder.
However, the familiar Sharing tab of a folder’s properties dialog box in Windows Explorer is available only when you configure a share while logged on to a computer interactively or through terminal services. You cannot share a folder on a remote system using Windows Explorer. Therefore, you will examine the creation, properties, configuration, and management of a shared folder using the Shared Folders snap-in, which can be used on both local and remote systems.
When you open the Shared Folders snap-in, either as a custom MMC console snap-in or as part of the Computer Management or File Server Management consoles, you will immediately notice that Windows Server 2003 has several default administrative shares already configured. These shares provide connection to the system directory (typically, C:\Windows) as well as to the root of each fixed hard disk drive. Each of these shares uses the dollar sign ($) in the share name. The dollar sign at the end of a share name configures the share as a hidden share that will not appear on browse lists, but that you may connect to with a Universal Naming Convention (UNC) in the form \\servername\sharename$. Only administrators can connect to the administrative shares.
To share a folder on a computer, connect to the computer using the Shared Folders snap-in by right-clicking the root Shared Folders node and choosing Connect To Another Computer. Once the snap-in is focused on the computer, click the Shares node and, from the shortcut or Action menu, choose New Share. The important pages and settings exposed by the wizard are
*The Folder Path page Type the path to the folder on the local hard drives so, for example, if the folder is located on the server’s D drive, the folder path would be D:\foldername.
*The Name, Description, and Settings page Type the share name. If your net-work has any down-level clients (those using DOS-based systems), be sure to adhere to the 8.3 naming convention to ensure their access to the shares. The share name will, with the server name, create the UNC to the resource, in the form \\servername\sharename. Add a dollar sign to the end of the share name to make the share a hidden share. Unlike the built-in hidden administrative shares, hidden shares that are created manually can be connected to by any user, restricted only by the share permissions on the folder.
*The Permissions page Select the appropriate share permissions.
Managing a Shared Folder
The Shares node in the Shared Folders snap-in lists all shares on a computer and provides a context menu for each share that enables you to stop sharing the folder, open the share in Windows Explorer, or configure the share’s properties. All the properties that you are prompted to fill out by the Share A Folder Wizard can be modified in the share’s Properties dialog box, illustrated in Beow Figure
The Properties tabs in the dialog box are
*General: The first tab provides access to the share name, folder path, description, the number of concurrent user connections, and offline files settings. The share name and folder path are read-only. To rename a share, you must first stop sharing the folder then create a share with the new name.
*Publish: If you select Publish This Share In Active Directory (as shown in Below Figure), an object is created in Active Directory to represent the shared folder.
The object’s properties include a description and keywords. Administrators can then locate the shared folder based on its description or keywords, using the Find Users, Contacts and Groups dialog box. By selecting Shared Folders from the Find drop-down list, this dialog box becomes the Find Shared Folders dialog box shown in Below Figure
*Share Permissions: The Share Permissions tab allows you to configure share permissions.
*Security: The Security tab allows you to configure NTFS permissions for the folder.
Configuring Share Permissions
Available share permissions are listed in Below Table. While share permissions are not as detailed as NTFS permissions, they allow you to configure a shared folder for fundamental access scenarios: Read, Change, and Full Control.
Read: Users can display folder names, file names, file data and attributes. Users can also run program files and access other folders within the shared folder.
Change: Users can create folders, add files to folders, change data in files, append data to files, change file attributes, delete folders and files, and perform actions permitted by the Read permission.
Full Control: Users can change file permissions, take ownership of files, and perform all tasks allowed by the Change permission.
Share permissions can be allowed or denied. The effective set of share permissions is the cumulative result of the Allow permissions granted to a user and all groups to which that user belongs. If, for example, you are a member of a group that has Read permission and a member of another group that has Change permission, your effective permissions are Change. However, a Deny permission will override an Allow permission. If, on the other hand, you are in one group that has been allowed Read access and in another group that has been denied Full Control, you will be unable to read the files or folders in that share.
Share permissions define the maximum effective permissions for all files and folders beneath the shared folder. Permissions can be further restricted, but cannot be broadened, by NTFS permissions on specific files and folders. Said another way, a user’s access to a file or folder is the most restrictive set of effective permissions between share permissions and NTFS permissions on that resource. If you want a group to have full control of a folder and have granted full control through NTFS permissions, but the share permission is the default (Everyone: Allow Read) or even if the share permission allows Change, that group’s NTFS full control access will be limited by the share per-mission. This dynamic means that share permissions add a layer of complexity to the management of resource access, and is one of several reasons that organizations cite for their directives to configure shares with open share permissions (Everyone: Allow Full Control), and to use only NTFS permissions to secure folders and files. See the “Three Views of Share Permissions” sidebar for more information about the variety of perspectives and drivers behind discussions of share permissions.
Managing User Sessions and Open Files
Occasionally, a server must be taken offline for maintenance, backups must be run, or other tasks must be performed that require users to be disconnected and any open files to be closed and unlocked. Each of these scenarios will use the Shared Folders snap-in.
The Sessions node of the Shared Folders snap-in allows you to monitor the number of users connected to a particular server and, if necessary, to disconnect the user. The Open Files node enumerates a list of all open files and file locks for a single server, and allows you to close one open file or disconnect all open files.
Before you perform any of these actions, it is useful to notify the user that the user will be disconnected, so that the user has time to save any unsaved data. You can send a console message by right-clicking the Shares node. Messages are sent by the Messenger Service using the computer name, not the user name. The default state of the Messenger service in Windows Server 2003 is disabled. The Messenger service must be configured for Automatic or Manual startup and must be running before a computer can send console messages.
Monday, February 1, 2010
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment