Setting up a Logon Script through GPO in Windows Server 2008

As written in the first part of this set of articles, there are two ways to assign Logon scripts. The first is done on the Profile tab of the user properties dialog in the Active Directory Users and Computers (ADUC). The second is done via Group Policy Objects (GPO). This article will focus on the second method.
There are a few benefits for using GPOs to assign scripts:

• GPOs only work with Windows 2000 and above, meaning that if your users use older clients such as Windows 95/98 or Windows NT, GPOs won't work for them.
• When using GPOs you can assign MORE than one logon script per user, and you can configure which script runs first.
• When using GPOs you can assign more than JUST logon scripts, you can also assign LOGOFF scripts for users, and even STARTUP and SHUTDOWN scripts for the computer itself.
• GPOs can be linked to OUs, Site or Domain levels, meaning that with one GPO you can assign a logon script to many users, or even to all your users, instead of having to manually adding it to all the user objects in the domain.

This is why for most scenarios, using GPOs is more useful than doing it the old fashioned way, through ADUC.
Note: Using Windows Server 2008 GPOs to assign logon scripts is mostly the same as it was in Windows 2003, but having some people asking me questions about it in Windows Server 2008 has triggered the writing of this article.

Creating the logon script

The logon script is the file that does the actual action. It could be almost any action, as noted above. So we'll start by creating that script. Unlike the "old fashioned" method of using ADUC and the Profile tab of the users' account properties, the default location for GPO-initiated logon scripts is the deep within the SYSVOL special folder, which, by default, is shared on all Domain Controllers in an Active Directory forest, and is located in the following folder:
%SystemRoot%\SYSVOL\sysvol\<domain DNS name>\Policies\{GUID}\User\Scripts\Logon
Where %SystemRoot% is usually “C:\Windows”, <domain DNS name> is the DNS name of the domain, similar to “Petri.local”, and {GUID} is a hexadecimal string representing the GUID (unique identifier) of the specific Group Policy Object in use. This folder, which is a part of the SYSVOL special folder, is replicated to all the Domain Controllers in the domain. Each GPO has its own internal User and Machine subfolders, and under them it has, if used, a Logon, Logoff, Startup and Shutdown subfolder where appropriate.
Note: The actual process of creating the script is beyond the scope of this article, there are planty of good resources with great examples on the Internet.

1. Create the logon script and give it the appropriate name (for example: logon.bat, logon.cmd, logon.vbs, etc.) The script can use ANY name, just make sure you know what that name is, and give it the right file extension type.
2. Make sure that the script runs and performs the required action when it is manually run (double-click on it).
3. Copy the logon script (CTRL+C).

If you plan to have more than ONE logon script, and if you wish to assign that/those script(s) to more than one user, you will need to create as many logon scripts as you want, and then add them in the right order in the right GPO. More on that, later.

What permissions are required for Logon scripts to run?

Logon and Logoff scripts run with the credentials of the user. It is recommended that the “Domain Users” group shall be given permission to any resources used by either of these scripts. For example, if the Logon or Logoff script writes to a log file, the group “Domain Users” should be given read/write access to the file or the folder where the log file is located. Most users have limited privileges on the local computer, so Logon and Logoff scripts will have the same limited privileges.
As a side note, Startup and Shutdown scripts run with the credentials of the computer object. It is recommended that the “Domain Computers” group shall be given permission to any resources used by the Startup or Shutdown scripts. However, it's worth knowing that Startup and Shutdown scripts have System privileges on the local computer. This gives Startup and Shutdown scripts access to the local file system and registry.

Assigning the script to the user or users

Next, we need to decide what user should have the logon script. With this procedure (and unlike the Active Directory Users and Computers method), you can link AS MANY logon script AS YOU WANT to your users, and you can do it as many times as you want. However, it will only work on computers that are Windows 2000 and above, although in most cases nowadays this is not a problem.
The title of this section is kind of misleading, because when using GPOs, you do NOT assign the GPO to a user or users, but to an Organizational Unit (OU), to an Active Directory Site, or to the entire Active Directory Domain. So, you must now decide if you want the script to apply to ALL THE DOMAIN USERS, or just to a specific set of users located within one or more OU (Organization Unit) in Active Directory Users and Computers.
If you choose to apply on all the users in the domain, you must create a Group Policy Object (or GPO) and link it to the ENTIRE domain. If you choose to apply the script ONLY to a SPECIFIC SET of users, you must place all the users in one OU (Organization Unit) in Active Directory Users and Computers, and link the GPO to that OU.
In order to assign the GPO and edit it, we'll use a tool called Group Policy Management console, or GPMC in short. This tool is not installed by default in Windows Server 2003, and neither is it installed by default in Windows Server 2008. In Windows Server 2008, GPMC is considered to be a "Feature", and you must install it before being able to use it. However, unlike in Windows Server 2003 where you must download and install the tool, in Windows Server 2008, GPMC is already a part of the OS, you simply need to add it. If the Windows Server 2008 server is also a Domain Controller, GPMC will be automatically installed as part of the DCPROMO procedure. If it's not a DC, you'll need to manually add it.

1. See if the Administrative Tools folder has a tool called Group Policy Management Console. If it does, read on.


2. Open Group Policy Management Console from the Administrative Tools folder (or gpmc.msc from RUN).
3. If, as described in the above paragraph, you decided to apply the script to ALL THE DOMAIN USERS, expand the domain tree, locate the domain name. Right-click the domain name and select Create and Link a GPO Here.
4. If, as described in the above paragraph, you decided to apply the script to ONLY a SPECIFIC SET of users, expand the domain tree, locate the OU where the users from are located. Right-click the OU and select Create and Link a GPO Here.

Note: Of course it might be possible that a GPO already exists and it is linked to the object level you need. In that case you don't need to create a new GPO, you can use the existing one.

5. In the New GPO window, give the new GPO a descriptive name, such as "Test Logon Script GPO". Click Ok.


6. If you don't see it already, refresh the GPMC view and find the new GPO you've just created under either the domain name, or the OU, depending on your previous choice.
7. When you click on the new GPO you might be prompted with a message window. Click Ok.


8. Right-click the new GPO and select Edit.


9. In the Group Policy Object Editor window, expand User Configuration > Windows Settings > Scripts.


10. Double-click Logon in the right-hand pane.
11. In the Logon Properties window, click Show Files.


12. A window will open. The path will be a folder similar to the following: \\domain.com\SYSVOL\Petri.local\Policies\{E4A62379-8423-4654-8DB6-01FB8F58582D}\User\Scripts\Logon. Paste the logon script you've copied in the previous part of this article. Close the window.


13. Back in the Logon Properties window, click Add.


14. In the Add a Script window, click Browse and you will see the logon script step #11. Whatever you do, DO NOT manually browse for the file, it should be in front of your eyes. If it's not there, check the previous steps for a mistake. Click Ok.


15. Back in the Logon Properties window, see if the logon script is listed, and if it is, click Ok.


16. Close the Group Policy Object Editor window.
17. Close the GPMC window.

Replicate the DCs

Now we need to replicate the DCs in the domain by using either Active Directory Sites and Services, Replmon, Repadmin, or wait a few moments (depending on the number of DCs). As a simple follow up to this article, I suggest you use Active Directory Sites and Services.

Testing the logon script

1. On one of the computers that is part of the domain, logoff the specific user account.
2. Logon and test.

If the logon script doesn't work for you, go back to the basics and see if it works at all by double-clicking on it. See if it's placed in the right path, and see if it has replicated to the other DCs. Also check permissions by trying to manually run the script from the right path but while logged on as the user, and not as an administrator. If it still doesn't work, use GPMC's Group Policy Results feature to determine of the GPO has indeed been applied to the user.

Read more »

Posted in: Window Server

erver 2008 R2's Best Practices Analyzer

One of the areas of managing Windows servers that has always been a little problematical is that of discovering so-called “best practices.” One can debate the extent to which it is the operating system vendor’s responsibility to advise as to how best to use its products, but just as the manufacturer of an automobile is in a uniquely well-informed position to advise its customers as to best practices in safety and reliability and performance, so too is the OS manufacturer uniquely positioned to help customers understand the “typical best way” of operating; on the understanding that informed customers may depart from a specific “best practice” as specific needs may dictate. The need for expert guidance on best practices increases as the complexity of the tool increases; we can use a bit more advice when driving a Prius than when riding a bicycle.
Windows Server 2008 took some steps towards helping customers with best practices by increasing the default security of roles installed via Server Manager. In addition, Server Manager became more intelligent, prompting us for example to install needed subsidiary roles (“role services”) when advisable or necessary. Windows Server 2008 R2 goes further and contains something called the “Best Practices Analyzer,” which is not exactly one thing but a combination of things built around something called the BPA “engine.”
The BPA engine interfaces with administrators in several ways. You can access it through Server Manager, of course; but you can also do so via PowerShell (and thereby Server Core). Clients can access BPA through the Remote Server Administration Tools (RSAT). As Microsoft refines its best-practices “advice,” and adds topic areas (initial ones include AD, DNS, Certificate Service, and IIS), updates to the BPA system will be made available through Windows Update. You can set up proactive BPA monitoring and reporting by creating an event log subscription that gathers BPA out-of-compliance events from multiple systems, and collects them on a central computer.
The BPA is not a new idea. In fact there have been BPA’s for other Microsoft products. But given the complexity and depth of Server 2008, it will be interesting to see how effective the BPA can be. It’s a good idea, but its usefulness will ultimately come down to how much time and effort Microsoft puts into the knowledge base that drives the engine, and how accurate the detection scenarios (and resulting bits of advice) are.

Read more »

Posted in: Window Server

Securing Windows Server 2008 R2 : Security Configuration Wizard & Best Practice Analyzer

Security Configuration Wizard

The Security Configuration Wizard (SCW) is a handy tool that was released as a part of the tool suite for Windows 2003 SP1. Its purpose is to allow you to create role-based security policies that can then be applied to any server in your organization. It allows for the repeatable configuration of security settings across multiple servers in an organization while maintaining consistency and reduction of administrative overhead; basically, all the characteristics administrators look for in a tool!

SCW comes in two flavors, the first is a GUI-based wizard-driven tool, while the second is a command prompt tool called scwcmd. One thing to keep in mind with both of these tools is that they do not perform any configuration changes related to installation and can only manipulate what already exists on the system. They are analysis tools that will examine the current state of your system and report on the findings. They will perform certain configuration-related actions on the local system, such as editing Windows Firewall settings and unused disabling services, but no new software installations can be performed with these tools. It is recommended that before you run the SCW you determine what applications will exist on the server for the particular role you are trying to secure. Then install and run those applications on the server where you are running SCW. This will ensure that SCW takes into consideration any ports and services required for those local applications when creating the security file.

So, the first thing SCW will do when executed is that it will prompt you for what action you are trying to perform. The choices vary between creating a new policy, editing an existing policy, applying a policy, and rolling back the last applied policy. These options are shown in Figure 1. Previously, rolling back was a task performed with the command line Scwcmd tool. With Windows Server R2, it is an available GUI-based option.

Figure 1. Security Configuration Wizard Configuration Options.

When selecting to create a new policy, the wizard will walk through analyzing your local system. It will allow you to review its findings of locally installed roles and features, and add or remove as appropriate. Part of the display will include a list of services that would be impacted if the new security policy were to be deployed to the local server. It will also allow you to select if you would like to evaluate and configure additional system settings such as network settings, registry settings, and auditing settings.

Once you complete the configuration settings, the last screen in the wizard will allow you to save your new security configuration file. However, before doing so, you will have the option to add Security Templates into the file if you would like. To save the file, you must choose a name and a file path. The file extension will be .xml. Once you have saved your new security file, you will be prompted to apply it to the local machine, but be aware that applying the file through the wizard imports the settings into the Local Computer Security Policy. These settings are always overridden by domain-based policies; however, it is a great idea to apply the policy locally anyway. Why? Well, by applying the policy to the local machine, you will be able to test to see if the computer has been impacted in the desired fashion. If there are problems with the machine after the policy has been applied, you then use the wizard to rollback the policy and then edit your .xml file to make the appropriate adjustments.

Once you are ready to deploy your policy on a larger scale, it is recommended to utilize Group Policy to target the appropriate machines. The Scwcmd command line tool will allow you to convert an SCW .xml security file to a GPO by issuing the scwcmd transform command. This will allow you to utilize the security file within AD and deploy it to multiple servers of the same role simultaneously. Before rolling out a new SCW security file through Group Policy, it is highly recommended that you test thoroughly.

Best Practice Analyzer

When companies develop software, they typically have created use-case scenarios that customers are intended to follow for deployment. Whether the software is targeted at the health care market and is used to print patient bar codes, or is written to be used in construction and is intended to track work streams and dependencies, each piece of software is design to be deployed and utilized in a particular way. Some infrastructure services, such as AD and DNS, must be built and maintained to enable many other products to function properly. To help facilitate best practice installations of key server roles, Microsoft has developed the BPA.

The BPA tool can be utilized from the Server Manager tool, or BPA actions can be initiated through PowerShell. The toolset is installed by default on Windows Server 2008 R2, and its function is to perform analysis actions. It is designed to determine if there are any existing configuration issues such as port blockages that may cause issues and common administrative problems with Windows Server roles.

Since the tool functions on a role basis, it can be found within Server Manager under the corresponding role that you wish to scan. See Figure 2 for a sample view. Currently, scan support is offered for only some of the server roles in existence, but additional roles will be made available and released through the use of Windows Update. Support currently exists for the following Windows Server 2008 R2 Roles:

• Active Directory Domain Services
• Active Directory Certificate Services
• Dynamic Host Configuration Protocol
• Domain Name System
• Internet Information Services
• Remote Desktop Services
• Network Policy and Access Services

Figure 2. BPA within Server Manager.

When the BPA is run on a particular role, the first step in the analysis is to go through and examine the local configuration of the role. The settings and status are compared against best practices across eight different categories. The categories each contain a subset of rules that the scanned system is to be compared against. The eight categories and their descriptions are as follows:

• BPA Prerequisites—Indication that a rule could not be applied. Results in this category do not indicate noncompliance, but instead indicate that compliance could not be validated since a prerequisite was not in place.
• Security—Indication of the risk of exposure to threats, loss of data, theft of data
• Performance—Indication if the role is able to process and respond within expected performance thresholds
• Configuration—Indication of problems with identity-related settings
• Policy—Indication of problems with Group Policy and Registry settings
• Operation—Indication of failure to perform designated function
• Predeployment—Indication of whether best practice rules are satisfied before the role is used in the production
• Postdeployment—Applied after all services have started and the role is running in production

The system will evaluate compliance against the category rules and group the results into one of the three compliance ratings:

• Noncompliant—the role does not meet the best practices conditions set forth in a rule
• Warning—the role does meet the best practices conditions set forth in a rule, but configuration changes may still be needed to remain compliant
• Compliant—the role meets the best practices conditions set forth in a rule

The output of running a scan with the BPA is displayed in Figure 3 and as you can see, it is sectioned off into the Good, the Bad, and the Excluded. Any rule that scans as compliance will be displayed in the Compliant tab, any rule that scans as noncompliant will be displayed in the Noncompliant tab, and any rule that you have chosen to Exclude shows in the Excluded tab. Warnings are grouped in with the noncompliance items and exclusions are identified by the administrator.

Figure 3. BPA GUI-Based Output.

Exclusions are administrator-configured and may shift over time for different roles. For instance, the first time you run the BPA, the noncompliance list may show a warning stating that all OUs should be set to be protected from accidental deletion. The first few times you might think it is pretty cool that the tool is looking out for you that way, but by the time you have run the BPA for the third or fourth time, you will probably tire of looking at the warning message, hence, the exclusions. By selecting the warning message and clicking the Exclude Result option, the warning will move to the Excluded tab and will continue to appear there each time that you run the BPA from then on. If you change your mind in the future and would like to include the warning message into the normal noncompliant view once again, you can do so by selecting the Excluded tab, highlighting the message, and selecting Include Result from the actions pane. See Figure 3 for a sample of BPA output.

BPA from PowerShell

A key discernment between running the BPA from the Server Manager console and using PowerShell cmdlets is that PowerShell enables you to run scans of multiple roles simultaneously. With the GUI rendition of BPA, you are limited to selecting a single role at a time, executing the BPA, and then examining the results. If a server has multiple roles installed, this can be a tedious and time-consuming process. The solution is the utilize PowerShell.

Before you can actually use PowerShell for BPA though, you must go through the steps of importing the correct modules. BPA requires that you impact both the Server Manager module as well as the Best Practices module. To import the modules, open PowerShell on your server and input the following commands:

Import-Module ServerManager

Import-Module BestPractices

At this point, you are ready to execute the BPA, but to discover what roles are installed on the server that you can run the BPA against, you should execute a Get-WindowsFeature command. Sample output is displayed in Figure 4.

Figure 4. Get-WindowsFeature Output.

From here, it is a matter of objective. You can now see which roles are on the server to which BPA applies, and the next step is to decide which ones you would like to run the BPA against. The easier choice is to follow the same format as the Get-WindowsFeature and use the filter to perform the BPA scan against all installed roles. The syntax for this command would be as follows:

Get-WindowsFeature | Where {$_.BestPracticesModelId -ne $null} | Invoke-BPAModel

Figure 5 displays the command execution results. One of the first things you will notice after running Invoke is that the output results display whether the run was successful or not, but what they do not show are the actual results. To see the results of the scan, you will need to utilize the Get-BPAResult cmdlet.

Figure 5. BPA PowerShell Execution.

Read more »

Posted in: Window Server

Configuring Windows Server 2008 File Sharing

Given that Windows Server 2008 is a server operating system it is not surprising that a primary function of this operating system is to serve files to users on other systems on a network. The primary focus of this chapter, therefore, is the sharing of files and folders on Windows Server 2008.

Standard and Public File Sharing

Windows Server 2008 supports two types of file sharing, referred to as public file sharing and standard file sharing.
In the case of public file sharing any files to be shared must be copied to the server's Public folder located at %SystemDrive%\Users\Public. Once placed in this folder the files are accessible to any users logged locally onto the machine and, if enabled, to any network users. Public sharing provides some control over access to the files. For example, when the server belongs to a workgroup the public folder can be password protected. In addition, network access to files within the public folder can be restricted to reading and executing only or given permission to read, write, create and delete files.
Standard file sharing, which is only permitted on NTFS volumes, allows individual folders files and volumes to be shared to specific users. This provides far greater levels of security over network access through a combination of NTFS file and folder permissions and share permissions, and avoids the necessity to move files from their existing location in order to share them.

Enabling Windows Server 2008 File Sharing

File sharing in Windows Server 2008 is managed from the Network and Sharing Center, accessed by selecting Start -> Network and clicking on the Network and Sharing Center button in the toolbar. Once invoked, the Network and Sharing Center will list the current file sharing configuration and options as illustrated in the following figure:

To enable public file sharing, click on the down arrow next to the Public folder sharing in the section entitled Sharing and discovery. This will provide the following list of public folder sharing options:

• Turn on sharing so anyone with network access can open files - Allows network users to open, but not delete, modify or create files in the server's public folder.

• Turn on sharing so anyone with network access can open, change and create files - Allows network users to open, modify, delete and create files in the public folder.

• Turn off sharing (people logged on to this computer can still access this folder) - Allow public folder access only to those users locally logged on to the server. Network users are denied access.

Similarly, standard file sharing can be configured by click the down arrow next to File sharing. When unfolded, this panel provides the option to either enable or disable standard file sharing on this server. When enabled, a dialog will appear providing the option to make the shared folders available only to the private network on which the system resides, or to make sharing available to public networks. The choice here depends on the requirements of the organization but for security purposes it is typically best to limit sharing to the private network unless external access is required.
The Network and Sharing Center also allows password access to shared folders to be configured. When the arrow next to Password protected sharing is selected the options to enable or disable password protection sharing are provided. When enabled on workgroup servers, only users with user accounts and passwords on the server will be able to access shared files and folders.

Creating Shared Folders with Windows Explorer

Shared folders can be configured using Windows Explorer, simply by navigating to the folder to be shared, right clicking on the folder and selecting Properties from the menu. In the properties dialog, click on the Sharing tab to display and modify the current shared folder settings as illustrated in the following figure:

Within the sharing property panel, click on the Share... button to access the File Sharing dialog. Within this dialog, the users who may access this shared folder are specified. If file sharing has been restricted to users with local accounts and passwords, a list of users can be obtained by clicking on the down arrow. In this situation, select and add users, or select Everyone if access is to be made available to all users with local accounts:



Once these settings are complete, click on the Share button to initiate the file sharing process. Once this initial phase of the share setup is complete a dialog will appear announcing this fact, listing the full Universal Naming Convention (UNC) path to the shared folder and providing the option to email users to notify them of this fact:



Having specified which users will have access to the folder the next step is to enable the sharing of the folder, specify share permissions and configure a Share Name by which the folder will be referenced and accessed. In addition caching of shared files can be configured. Caching allows users to maintain local copies of shared files so that they can be accessed off-line (for example when the server hosting the files is not available to the user's local system). With caching configured, local copies of shared files are stored on the user's local system so that they can be accessed without a connection to the server. When a connection is re-established, any changes made to the local copy of the file are synchronized with the original copy on the server.
To configure these settings, click on the Advanced Sharing button to display the following dialog:

In this dialog, set the Share this folder option to enable the sharing of the folder. Once this has been selected the Share name field and associated button will activate enabling a share name to be entered. By default the name of the folder being shared will be displayed, although this may be changed to another name if desired. If the number of concurrent users accessing a shared folder is of concern, modify the number of simultaneous users accordingly. Enter optional comments about the share before clicking on Caching to configure the off-line file settings. This will invoke the Offline Settings dialog where a number of options are available including allowing each user to specify which files they would like to be able to access off-line, only having files that users actually access available off-line and disabling off-line sharing all together:



The final step in the folder sharing setup is to click on Permissions to configure the share permissions, details of which are covered in a later section of this chapter.

Creating Shared Folders on Remote Servers with Computer Management

Windows Explorer provides an excellent mechanism for configuring shares on the local system. This approach falls a little short in terms of convenience, however, when it is necessary to configure shares on a remote server. Fortunately Windows Server 2008 addresses this need by allowing shares to be configured from the Computer Management tool. One point to note is that while this section will focus on the remote configuration of file shares, the steps outlined here may equally be used to share files on a local server. In fact, the Create a Shared Folder Wizard can be invoked on a local machine either from Computer Management or by entering shrpubw at the command prompt or in a Run dialog.
After starting Computer Management on the local system, right click on Computer Management in the left panel tree and select Connect to another computer... In the resulting dialog box either enter the name of the remote computer or click on Browse and then Advanced... to search the network or domain for the remote system. Once a connection has been established to the remote server the Computer Management interface will refresh and the Computer Management link in the tree will also display the name of the selected remote server.
Once Computer Management is configured to administer a remote server, the next step is to begin the folder sharing process. Begin by unfolding the System Tools, then Shared Folders branches of the tree in the left panel. Select Shares to obtain a list of current shares configured on the remote system. The following figure illustrates Computer Management with a list of shares configured on a remote system named WINSERVER-2:



The creation of a new shared folder on the remote server (although as previously mentioned this can also be used on local computers) involves the use of something called the Create A Shared Folder Wizard, which, as the name suggests provides a user friendly way of configuring shared folders. To invoke this wizard, simply right click on New Share..., then click on Next on the wizard's welcome screen. In the resulting Folder Path screen, either type in the path of the folder to be shared, or browse the file systems to locate it. With the required folder path selected click on Next to configure the name and description settings. On this screen, specify the share name by which the folder will be accessed from remote computers together with an optional description of the shared folder. Next, configure the off-line file settings for the folder contents by clicking on Change.
Once these settings are configured, click on Next once again to configure the share permissions for the selected folder. Either select one of the pre-configured options or select Customize permissions and click on Custom to configure share permissions on a per user basis.
Finally, click on finish to complete the sharing process. If the configuration is successful a summary screen similar to the one illustration in the following figure will be displayed:

Creating Hidden Shares

By default, shared folders are listed when users browse for shared resources. From time to time, however, it may be necessary to share a folder but have it hidden such that only users who know of its existence can access it by referencing the share name. This concept is known as hidden share access. The most important point to note about hidden shares is that it does nothing to prevent access other than hiding the fact that the share exists. If, for example, a user learns of the existence of a hidden share (perhaps because another user tells them about it), and the share permissions are such that they have access to the folder, the fact that it is hidden will do nothing to keep the user out of that folder.
Shares are made hidden by placing a $ at the end of the share name. For example, to hide a share located at C:\accounts simply give it a share name with a trailing $, such as accounts$.

Understanding and Configuring Share Permissions

As outlined at the beginning of this chapter, Windows Server 2008 provides two levels of permissions for shared files and folders, namely share permissions and file and folder permissions. Share permissions are applied when access is made via the network. When shared files and folders are accessed locally from the server on which they reside these permissions serve no purpose. File and folder permissions, on the other hand, take effect both when accessing files and folders both locally and over the network. In the case of network access to shared files and folders, the shared permissions are applied first, followed by any file and folder permissions. The key issue to note is that file and folder permissions provide a far greater level of control over access than the more general permissions options provided by share permissions. In this section, share permissions will be covered. For details on file and folder permissions refer to the chapter entitled Understanding Windows Server 2008 File and Folder Ownership and Permissions.
Share permissions are granted on a per user and per group basis. In addition to allowing a cap on the number of concurrent users accessing a share to be defined, share permissions also provide three permission options, each of which can be set to Allow or Deny:

• Full Control - Grants the specified users permission to change file and folder permissions, execute, read, modify, create and delete files and sub-folders.

• Change - Grants users permission to change file and folder attributes, read, modify, execute, create and delete files and sub folders.

• Read - Grants users permission to read and execute files and view and access file lists and sub-folders.

Permissions are cumulative in that a user will inherit the permissions of all the groups of which he or she is a member. If a permission is Denied, however, it overrides any cases where that permission may have been granted. For example, if a user is a member of a group where full control is provided over a folder, and also a member of a second group where full control is specifically denied, the user will be denied full control regardless of the fact that it was granted in the first group.
To configure share permissions, start Computer Management, connect to a remote server if not working on local shares, unfold System Tools and select Shares to list all currently shared folders. To configure share permissions for a folder, select it from the list, right click and select Properties. In the properties dialog select the Share Permissions tab as illustrated in the following figure:



This screen displays the current share permissions and provides the ability to configure additional permission controls. To change the settings for a currently configured group or user select the user from the list, modify the permissions accordingly and click on Apply to commit the changes.
To add permissions for a specific user or group click the Add button and enter one or more users or groups into the text box (separating multiple entries with a semi-colon) and click on Check Names to verify the names are correct. Click on OK to return to the properties dialog where the added users and groups will appear in the list. Once again, select each name in turn and configure the desired share permissions. Finally, click Apply to commit the new permissions.

Read more »

Posted in: Window Server

How do I... Install and configure a DHCP server in Windows Server 2008?

Takeaway: DHCP is an invaluable service when you have a network larger than a handful of computers. Microsoft Windows Server 2008’s built-in DHCP server allows Windows machines to obtain their IP addresses and network settings automatically, which can vastly simplify network configuration. Steven Warren describes how to install and configure a DHCP server in Windows Server 2008, and explores some of the advanced features DHCP has to offer.

Dynamic Host Configuration Protocol (DHCP) is an invaluable service when you have a network larger than a handful of computers. It’s also a standard component of enterprise networks and sub networks. Microsoft Windows Server 2008’s built-in DHCP server allows Windows machines (and any other TCP/IP-based machines and devices) to obtain their IP addresses and network settings automatically, which can vastly simplify network configuration. In this document, we’ll discuss how to install and configure a DHCP server in Windows Server 2008, and we’ll explore some of the advanced features DHCP has to offer.
This blog post is also available as a TechRepublic gallery and TechRepublic download.

Create a plan

Before you configure your DHCP server, it is a good idea to have all your ducks in a row. Prepare and have all the necessary information up front before sitting down and configuring your server. For example, you may need to know:

• The scope of IP addresses that your server will manage (e.g., 192.168.1.50 to 192.168.1.200).
• Which machines require static IP addresses (i.e., those machines such as servers and routers that will not use DHCP to receive their IP addresses but will be set manually).
• Which network information you want to send out to DHCP clients when they get their IP addresses (e.g., the addresses for your default gateway, DNS servers, and WINS servers).

It is much easier to configure your DHCP server with this information in hand rather than scrambling for it at implementation time.

Installing DHCP

Installing a DHCP server in Windows 2008 is a snap. They created a very simple wizard that walks you through the entire process. Follow me on this journey.
To install a DHCP server from the Control Panel, follow these steps:

1. From the Start menu, select | Control Panel | Administrative Tools | Server Manager.
2. Expand and click Roles (Figure A).
3. Choose Add Roles and follow the wizard by selecting the DHCP role (Figure B).
4. A new DHCP wizard appears to help you configure a DHCP server.

Figure A

Server Manager

Figure B

Add Roles Wizard

In the previous release of Windows, a wizard did not appear to walk you through creating a DHCP server. Windows Server 2008 has really simplified this process by allowing you to configure a DHCP server in roughly seven steps. Of course, you can still manage your DHCP server from the DHCP Microsoft Management Console (MMC) snap-in or delete and create scopes on the fly.
Let’s continue on through the wizard. Your network cards and static IP addresses are automatically detected and you can choose how DHCP will service clients on different subnets, as shown in Figure C.

Figure C

 

Choose your static IP addresses to service DHCP clients

On the next window (Figure D), you can specify the applicable DNS server(s) to be used with DHCP when an address is assigned. Figure E displays where you would enter the applicable WINS servers if you require it on your network.

Figure D

 

Enter your DNS server IP address

Figure E

Enter your WINS server IP address

About scopes

When you create a scope, you must select the range of IP addresses and you must specify the appropriate scope options to include. These options are what we were referring to above when we mentioned that you can assign other network information to your clients at the time they are given an IP address.
There are two types of scope options: Global and Scope. Global options are propagated to all the scopes that you create on that DHCP server, while Scope options are only for the individual scope that you are working with.
For example, if you have different scopes for several different subnets and each subnet will have a different default gateway but will share the same DNS servers, you would want to set the DNS servers as a Global option while the default gateways would be set separately in each scope as a Scope option.
On the DHCP scope window, you will create your scope. Depending on the size of your network and the amount of users that will be assigned IP addresses, some thought must be given to the parameters of your scope selections. In my example (Figure F), I created a simple scope.

Figure F

 

Creating your scope

The subnet type dropdown allows you to choose wireless as well (Figure G). It defaults to 24 hours. If you want to activate the scope when the wizard is complete, click the Activate this scope checkbox. If you leave it empty, you must activate the scope in the DHCP Microsoft Management Console (MMC) snap-in.

Figure G

 

You can add multiple scopes before continuing the wizard

With Windows Server 2008, if you have a router (Figure H) that supports and is configured to take advantage of IPv6, you can enable this functionality on your network.

Figure H

 

Enable IPv6 stateless mode

Authorizing the DHCP server and activating scopes

In previous versions of Windows Server, you had to install and configure your DHCP server and then authorize it in the DHCP MMC snap-in. Authorizing your DHCP server allows you to prevent hackers from configuring rogue DHCP servers. In Windows Server 2008, you have the ability to either authorize the server in the Wizard or authorize it after the fact in the DHCP MMC-snap-in (Figure I).

Figure I

 

Authorizing your DHCP server

You are now ready to review (Figure J) and confirm your settings before applying your DHCP settings (Figure K).

Figure J

 

Reviewing your DHCP configuration before applying

Figure K

DHCP installation in progress

Once you have installed the DCHP server, you can manage it from the DHCP MMC snap-in (Figure O) located in Administrative tools. On this screen you can create additional exclusions and reservations.

Adding reservations

In addition to specifying exclusions, you can add reservations to your DHCP server. By adding a reservation, you ensure that a machine always receives the same IP address from the DHCP server.

1. Right-click on Reservations and choose new reservation.
2. Enter a friendly name for the reservation and the IP address you want to assign to the computer or device.
3. Enter the MAC address of the computer or device. (For Windows machines, you can find the MAC address by running ipconfig/all from the command prompt of the machine.)
4. Enter a description and then choose the following reservation type: DHCP, BOOTP (going across a router), or both, as shown in Figure L. Click Add.

Figure L

 

Adding a reservation

Adding exclusions

In addition to specifying reservations, you can add exclusions to your DHCP server (Figure M). By adding exclusions, you ensure that machines never receive a DHCP lease for that range of IP addresses. This is very useful to block IP addresses for your servers and routers.

Figure M

 

Adding an exclusion

In order to add Exclusions, right-click on Address Pools and choose New Exclusion Range as shown in Figure N and Figure O.

Figure N

 

P address Exclusion range

Figure O

DCHP MMC snap-in

Troubleshooting DHCP

After configuring DHCP, the easiest way to troubleshoot it is to use Ipconfig from a command prompt. To view all TCP/IP information on a machine just type ipconfig/all. To release a DHCP lease, type ipconfig/release; to renew a lease, type ipconfig/renew.

 

 

Read more »

Posted in: Window Server

Set up DNS on Windows Server 2008 (R2)

If you’re like me and run your websites on Windows Server 2008, you might have had the need to set up your own DNS services and use your own nameservers on it. If you’re not a big networking person (like me), this can prove to be a little confusing to do yourself. Let’s jump right into this and get started.

If you haven’t already you’ll need to add the DNS Server role to your server before you can continue with the next steps. Installing a new role is fairly straightforward, if you need help check out this article.

Create a New Forward Lookup Zone

Once the role is installed and you’re in the server manager, drill down the treeview in the server manager by expanding Roles → DNS Server → [machine name] → Forward Lookup Zones. Right click Forward Lookup Zones and select New Zone…

 The new zone wizard should open up, click the Next button. We’re going to be creating a Primary Zone, so select the radio button and hit Next.

 Next it will ask you for a zone name, this will be the domain name you are setting up so for example, domain.com. Click the next button once you’ve entered your domain.

Next the wizard will ask you if you want to create a new zone file or use an existing. Leave everything as default and click next.

 On the next screen it’ll ask you whether you want to allow dynamic updates. You can leave the default Do not allow dynamic updates selected and click next.

Finally, click the Finish button.

Add the Nameserver Entries

Right click the zone we just added in the server manager treeview and select Properites. Select the Name Servers tab. There should already be a default entry for the nameservers, you can remove this by selecting it and clicking the Remove button. Next, click the Add button. In the New Name Server Record window, enter the full qualified domain name in the space provided, so for example, ns1.domain.com. Next click where it says <Click here to add an IP Address> and enter the first IP address you’ll be using. Click the OK button to add the first entry.

 Repeat this step for the second IP address you should have, but use something like ns2.domain.com for this one. When finished, you should have something that looks like this:

Click the OK button.

Add a Host Record

Next we’ll create a host record for our zone. Right click the zone and select New Host (A or AAAA). You can leave the name field blank as this will use the name of the zone (domain.com). Enter the ip address this domain will be using and click the OK button.

Add a WWWAlias

Chances are you’ll probably want people to be able to connect to your domain by typing www.domain.com and not just domain.com. We can add an alias for www. To do this, right click your zone and select New Alias (CNAME). For the Alias name, enter www. For the fully qualified domain name, type domain.com and click the OK button.

You would also add subdomains this way, so if we wanted sub.domain.com we would set it up the same way as above, replacing the alias name with sub.

The Final Product

When all is said and done, you should have something similar to this:

 Hopefully this helped you with getting DNS set up. I will post later about adding MX entries and also SPF records, but that’s all for now. Enjoy!

Read more »

Posted in: Window Server