Recent Posts

Showing posts with label Windows Server 2008. Show all posts
Showing posts with label Windows Server 2008. Show all posts

Auditing user accounts in Server 2008 R2

Windows Server 2008 R2 Group Policy permits administrators to audit status changes to user accounts. Here's a look at this feature.


Windows Group Policy is a powerful collection of configuration elements, and it can roll nicely into security configurations required for organizations of various types.

One Group Policy configuration that may be useful is the User Account Management Audit Policy. This policy allows user account audits for events, including object being changed, created, deleted, renamed, enabled, and disabled, password changes, permissions assignment changes, and other actions.

You can get to this setting by going to Computer Configuration | Windows Settings | Advanced Audit Policy Configuration | Account Management | User Account Management. The policy is shown in

Figure A
Figure A
Click the image to enlarge.
Once you enable this configuration, relevant events are passed into the Windows Security log for user account objects.
Let's go through a quick example with this audit configuration in place. On a test server, I did two events that will cause an audit event: I enabled the guest account, and then I changed the password for that account. Once those two tasks were done, these events were logged in the Security log on the local server.

Figure B shows the password event being logged.

Figure B
Figure B


This audit configuration can be managed centrally with Group Policy and configured for event forwarding. This auditing can be beneficial to monitor accounts for change records for selected accounts.
READ MORE - Auditing user accounts in Server 2008 R2

Patching Windows Server 2008 Core Edition

Every version of Windows Server needs a patching strategy. Find out some options for patching a Windows Server 2008 Core installation system.

Face it--patching is a necessary evil. A risk is always incurred when making a change to a production system, yet unpatched Windows servers are a greater risk over time.
Windows Server 2008's Core installation makes this a little more difficult. The good news is that there are a number of ways to patch the Explorer-less Windows Server.
Here are four ways you can go about patching the Core installation.
1. You can use a Microsoft automated solution such as System Center Systems Management Server (SC-SMS) or Windows Software Update Services (WSUS). This is likely the best option because it can be centrally managed, and update approval, installation time, and reboot behavior can be controlled.
2. You can use a four line script like the one below, and it can configure the server to install all updates. The last line will instruct the server to look for updates right away:
script c:\windows\system32\scregedit.wsf /au 4
Net stop wuauserv
Net start wuauserv
Wuauclt /detectnow
3. You can modify the configuration for the local Windows Update via the registry. This is the path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\

WindowsUpdate\Auto Update
Note: Editing the registry is risky, so be sure you have a verified backup before saving any changes.
4. You can use a non-Microsoft solution to manage the updates for the Windows Server 2008 system. This may include the Visual Core Configuration tools, Codeplex Windows Server 2008 Core Configuration, and Portlock Windows Update Manager.
There are a number of factors that will determine which tool will fit your needs best. Many organizations will be inclined to take the natural choice of using WSUS or SC-SMS, but it's good to know that other options are available.
How are you approaching the ongoing automatic updates for a Windows Server 2008 Core? Share your comments in the discussion.
READ MORE - Patching Windows Server 2008 Core Edition

Windows Server 2008 R2 features PowerShell 2 by default

For the Windows OS, few tools hold more weight than the PowerShell scripting environment. In this tip, Rick Vanover breaks down the new environment for Windows Server 2008 R2.

Windows Server 2008's R2 incremental release offers PowerShell 2.0 installed by default. For the base release of Windows Server 2008, you have to explicitly add PowerShell.
PowerShell 2 is currently available as a community technology preview (CTP) at version 3 to replace existing PowerShell 1 installations. The PowerShell 2 that is currently in Windows Server 2008 R2 is slightly different than the CTP that has been available.
PowerShell 2 introduces quite a bit of new functionality and some changes to cmdlets within PowerShell. While these changes are minor and generally accommodate additional parameters, you should give consideration to existing scripts. The release notes document on the Microsoft Web site has a full breakdown of the current PowerShell 2 changes and upgrades.
With these new functions and cmdlets, it would be worth testing any PowerShell 1.0 scripts out on a PowerShell 2 environment to ensure the scripts run correctly.
With all of the new PowerShell 2 features, it's a good time to line up the resources you need to write good PowerShell scripts. Here are some of the best resources that can help you make the transition to PowerShell 2:
  • Windows PowerShell Blog: The official Microsoft blog for PowerShell.
  • PowerGui.org: A community site affiliated with Quest software which has many PowerShell resources, including their own build that can integrate into other products such as Active Directory, VMware Infrastructure, and SQL through its PowerPacks.
  • The PowerShell Guy: A good resource for scripting.
Given that PowerShell will be a default configuration for Windows servers going forward, it's a good idea to have resources lined up for scripting.
READ MORE - Windows Server 2008 R2 features PowerShell 2 by default

Stopping AD Domain Services in Windows Server 2008

Windows Server 2008 introduces the service-controllable domain services, which allow for explicit management of domain controller servers. Rick Vanover shares tips on using this functionality.

Windows Server 2008 systems with the Active Directory Domain Services role installed have an extra element of functionality (compared to previous versions of Windows Server) in the "stoppable" services for the domain.
This works by Active Directory Domain Services being explicitly enumerated in the Services applet of the Control Panel. One of my pet peeves in Windows is services that do not permit the processing of a stop and start command. Terminal Services is the holdout, as Active Directory can now be explicitly stopped.
Active Directory Domain Services is managed as NTDS in the Services applet. You would use NTDS if you were using the sc command to manage Active Directory. You can also manage these services interactively. Figure A shows Active Directory being stopped on a Windows Server 2008 domain controller.
Figure A
Figure A
Click the image to enlarge.
Exercise caution
While this functionality is good for Windows administrators, you need to exercise caution. The first thing you should understand is what happens when Active Directory is stopped.
In environments with multiple domain controllers, the other systems would process logon requests. If there are any roles on the server with the stopped services, they will resume when Active Directory is resumed. If the outage will be for an extended period of time, it would be a good idea to transfer the role to another domain controller.
For normal maintenance, such as applying Windows updates or basic hardware maintenance, going without the role for a short amount of time is usually fine.
Also consider this question: Just because you can stop Active Directory, should you? I'm going to wait until Windows Server 2008 R2 before fully upgrading Active Directory because of some of the new features, and it will fit my timeline better.
READ MORE - Stopping AD Domain Services in Windows Server 2008

Use Access Based Enumeration to prevent users from seeing objects they can't access

Windows Server 2008 now includes a feature for administrators to hide files and folders from users who do not have read permissions to these objects.

On a company network, many different departments have their own shares to create folders and store documents. For example, a member of the marketing team may have read permissions to all or most of the folders in the marketing network share, but probably not to folders in the shares for Human Resources or Finance.
Previously in versions of Windows Server, even though users didn't have permissions to access the documents in other network shares, they could still see the folders that held them.
Access-based Enumeration (ABE) is a new feature available as part of the file server role in Windows Server 2008 (and as a download for Windows Server 2003). It will allow an administrator to hide objects from view on an entire server or on a per-share basis.
When enabled for a file share, users who do not have read access to objects would not be able to see those objects. Hiding these objects would prevent nosy (or worse) users from trying to access confidential files and could clear up some of the confusion caused by a bunch of "access denied" messages when trying to open them.
There are a number of privacy or security reasons why the folder names in Accounts Receivable, for example, shouldn't be viewable by the rest of the company. When the ABE feature is enabled on the file server, a user browsing the file share would not be able to see the Accounts Receivable folder at all.
Making use of the ABE feature can help clean up file shares by hiding the folders that users don't need to see, and it reduces the number of calls to the help desk from users who are trying to gain access to things they do not need, whether out of confusion or mischief. It could also keep unauthorized people out of files that do not have appropriate permissions set due to someone's oversight.
Note: The ABE features work only on Server Message Block (SMB) shares. If a user has access to a file server via Remote Desktop, the entire contents of the share will be visible.
Other network operating systems, such as Novell Netware, have had access enumeration features for many releases, leaving one to wonder why Microsoft has waited so long to introduce it. The argument is that the feature isn't needed if properly configured permissions on objects are already in place, but that doesn't necessarily cover all the reasons one might want to hide the names of certain folders.
You can download ABE for Windows Server 2003 Access-based Enumeration. Windows Server 2003 SP1 is required to install the feature.
READ MORE - Use Access Based Enumeration to prevent users from seeing objects they can't access

Configure printer pooling in Windows Server 2008

Printer pooling can consolidate print operations for Windows-based printing, which can lead to increased performance and cost savings.

Managing printers can be the bane of a Windows administrator.
One feature that may assist you with this task is the Windows printer pooling feature. Windows Server 2008 (as well as previous versions of Windows Server) offers functionality that permits a collection of multiple like-configured printers to distribute the print workload.
Printer pooling makes one share that clients print to, and the jobs are sent to the first available printer. Configuring print pooling is rather straightforward in the Windows printer configuration applet of the Control Panel.
Figure A shows two like-modeled printers being pooled.
Figure A
Figure A
Click the image to enlarge.
You should use logical guidelines when implementing printer pooling. In the line-of-business world, it makes great sense to use printer pooling where any batch, order, or other large print jobs are frequent. Slower printers, especially high-quality color laser units, may have a slower page per minute (ppm) rate than traditional black laser or ink devices.
Printer pooling makes sense in that situation if the number of print jobs warrant two of the high-cost devices.
To use pooling, the printer models need to be the same so that the driver configuration is transparent to the end device; this can also help control costs of toner and other supplies. But plan accordingly--you don't want users essentially running track to look for their print jobs on every printer in the office.
If you've seen the benefits of Windows-based printer pooling in your work environment, please share your comments in Talkback.
READ MORE - Configure printer pooling in Windows Server 2008

Options for passing a driver into Windows Server 2008 install program

he Windows Server 2008 installation offers a little flexibility on how drivers are installed. Find out some ways to access mass storage drivers in this article.

In a previous tip, I described how to load mass storage drivers during the Windows Server 2008 installation process.
However, many administrators may come across situations where a driver load becomes a challenge due to hardware and environment configurations.
Windows Server 2008 makes this process a little more flexible. Here are various ways that a driver can be passed into the setup program.
  • IDE floppy disk: I'm going old school here, but the Windows Server 2008 setup can read from the floppy drive during the installation process.
  • USB floppy drive: The Windows setup can read from a USB drive, or the computer's BIOS will enumerate the floppy drive as an A:\ drive. It's somewhat of a cover song of the old school approach.
  • USB flash drive: The Windows Server 2008 install will recognize USB storage devices, and you can have the driver located on the removable media.
  • Map a network drive: Yes you can! This is a little more advanced, but if you boot the server from a Vista PE bootable environment, map a network drive, and then run the setup.exe program interactively from a network location that you copied from the Windows Server 2008 DVD, you can browse to another network resource for a driver for the mass storage controller. This is especially beneficial if the Vista PE boot environment can be booted from a CD instead of a DVD, which is helpful for servers without a DVD drive. (For more information about Vista PE, read this TechNet article.)
  • Place the driver on an existing file system: If you can boot the server currently, make a drive partition of NTFS or FAT, you can put the driver on that drive and ensure it is available to the Windows Server 2008 install. Don't make it available on the C:\ drive, but some location at the end of the drive. If you need to resize your drives after installation, no worries--Windows Server 2008 makes that quite easy as well with new sizing tools.
  • Additional optical drives: If your server has a DVD and a CD drive, you can make a simple disk that has the driver files contained there and browse to that location during the Windows Server 2008 install.
The list goes on, but this will cover most of the common scenarios for interactive Windows Server 2008 installations.
If you've had to get creative on passing drivers based on server equipment configuration, share your experiences in the Talkback section below.
Rick Vanover is a systems administrator for Safelite AutoGlass in Columbus, Ohio. He has more than 12 years of IT experience, and he focuses on virtualization, Windows-based server administration, and system hardware.
READ MORE - Options for passing a driver into Windows Server 2008 install program

Manage local group policy on Server 2008 Core Edition

In situations where you need to access group policy on Windows Server 2008 Core Edition, they usually can be addressed by a domain group policy configuration. Here's how to get it done.

In Windows Server 2008 Core Edition, you can manage the group policy remotely through a MMC snap-in.
To configure this, you'll need to go through a few hoops. First, get a MMC snap-in pointed to the Windows Server 2008 Core Edition server. For a default configuration, you'll need to configure Windows firewall to allow this traffic.
This command will stop Windows firewall:
netsh advfirewall set allprofiles state off
When the Group Policy configurations are finished, run this command to turn firewall back on:
netsh advfirewall set allprofiles state on
From a remote system, run MMC.exe, add the Group Policy Object, and point it to a remote system. Figure A shows a remote system being pointed by TCP/IP address.
Figure A
Figure A

Click image to enlarge. Once saved, the local console can interact with the remote group policy configuration of the core server. This can work in conjunction with a domain-based Group Policy configuration if applicable. Be sure not to overlap, as the domain configuration will override a local configuration by re-application.
Permissions need to be in place for this to work correctly. This can include using domain-based credentials or passing administrative credentials manually with the 'net use' command.
The snap-in can be saved for future use, making it easier to access the core server's local Group Policy easier. Figure B shows the snap-in being saved for the core server.
Figure B

Figure B
Click image to enlarge. Remember to turn the Windows firewall on if you turned it off. Now you're finished!
It would be best to keep MMCs for the local Group Policy configuration of Windows core servers by computer name or IP address and store centrally for other administrators to access if required. This can save setup time for frequent access.
READ MORE - Manage local group policy on Server 2008 Core Edition

Enabling Remote Desktop on Server 2008 Core Edition

Remote Desktop is the lifeblood of Windows server administrator. Find out how simple it is to enable remote connections on the Core Edition of Windows Server 2008.


You've installed Windows Server 2008 Core Edition, so now what?

For most Windows systems, remote desktop protocol (RDP) is the key mechanism to administer the server. While there are not many things that can be done locally on a Core server, it is still beneficial to have access to a session locally on the system.

Determining how to do this is easy enough from Microsoft KB article 555964, but before we do this, we want to focus on the options involved.

RDP connections are available in two modes for Windows Core servers: (1) only allowing other Windows Server 2008 and Windows Vista connections or (2) permitting Windows XP, Windows Server 2003, Windows Server 2008, and Windows Vista connections. The difference is network level authentication (NLA), which Windows Vista and Windows Server 2008 support. NLA performs the authentication through various features of the newer products before starting the Remote Desktop session and passing the display to the client.

For more about NLA and the other components, read this blog post by the TechNet Performance Team.
Once you decide on a mode, it's quite easy to implement RDP on a Core system. If you want to use NLA for RDP connections to Windows Vista and Windows Server 2008 systems, enter this command on the Core server:

Cscript %windir%\system32\SCRegEdit.wsf /ar 0

To not use NLA and allow connections from all RDP clients, perform the step above and add this line:
Cscript %windir%\system32\SCRegEdit.wsf /cs 0

The server will accept RDP connections based on the mode selected. You're done!

Note: The commands in this tip will also work on the full installations if you want to roll them into a build script.
READ MORE - Enabling Remote Desktop on Server 2008 Core Edition

Manage BIOS updates with Windows Server 2008 Core Edition

BIOS firmware updates can be tricky without a native interface on the OS. Rick Vanover breaks down some options in this tip.

For Windows Server 2008, the Core Edition has scenarios where its use is appropriate.
In some cases, the Core Edition is even required like the free version of Hyper-V. For managing the hardware, this throws some curveballs to the Windows administrator. Here is what I have been doing to manage firmware and OEM hardware driver updates.
Install a third-party browser
The first thing I do is install Opera on my Core Edition servers--primarily because using Opera on the Core Edition will give a crude file manager function by typing C:\ in the address bar.
To install Opera, simply download it from another system and save the installation file to the C:\ drive of the Core Edition server and run the setup. From there, I can get the server's updated BIOS firmware. Figure A shows Opera functioning as a file browser.
Figure A
Figure A
Click the image to enlarge.
I prefer Opera, but other browsers may work. Remember, the Core Edition has no version of Internet Explorer, but other versions are installable on Core.
Get drivers and updates
For the hardware updates, you can get them from a local resource or the server support page and download them like you would on a full installation version.
I recently updated an HP ProLiant ML350 G5 server to the latest BIOS, version D21 on a Windows Server 2008 x64 Core Edition system. The online flash tools for HP will run in the same fashion as they would on a full installation version. Figure B shows the installation of the update after the download.
Figure B
Figure B
Click the image to enlarge.
Legacy mechanisms such as floppy-based flashing are still possible, but they are archaic and more time-consuming than some of the online mechanisms available. It is worth going through the learning curve on Core Edition to maintain the same flexibility levels as the full installation versions of Windows Server 2008.
Rick Vanover is a systems administrator for Safelite AutoGlass in Columbus, Ohio. He has more than 12 years of IT experience, and he focuses on virtualization, Windows-based server administration, and system hardware.
READ MORE - Manage BIOS updates with Windows Server 2008 Core Edition

Configure the screen saver timeout in Windows Server 2008 Core Edition

Managing the display settings in the Core Edition is a little less intuitive than its full install counterparts. Here's how to set the screen saver timeout in the registry.


The core installation of Windows Server 2008 does not have the familiar display or personalization settings configuration that we have become comfortable with in prior versions of Windows and the full install versions of Windows Server 2008. You can configure the screen saver timeout in the Windows registry for Core systems.

On a per-user basis, the screen saver timeout is set in this registry location:

HKEY_CURRENT_USERControl PanelDesktopScreenSaveTimeOut

Depending on the current configuration, a group policy object may have pushed down a different configuration in Active Directory and Group Policy environments. To set a timeout value, simply run Regedit from the core prompt and browse to this location in the registry. From there, you can open up the ScreenSaveTimeOut value and tweak the default value of 600 (10 minutes).

In this hive of the registry is the ScreenSaverIsSecure value. If this value is set to 0, it means that a password is not required to exit the screen saver; if the value is set to 1, it means that a password is required to exit the screen saver.

Figure A shows this area of the registry with a five minute screen saver timeout and a password being required to exit the screen saver.

Figure A
Figure A



These settings are not new to Windows Core Editions, but configuring these values in this fashion may be new for administrators. Another approach is the traditional Group Policy configuration, where domain membership and organizational unit placement will configure these settings centrally. This approach to the configuration is good for workgroup or standalone systems.

Note: Editing the registry can be risky, so be sure to have a verified backup before making any changes.
Rick Vanover is a systems administrator for Safelite AutoGlass in Columbus, Ohio. He has more than 12 years of IT experience, and focuses on virtualization, Windows-based server administration, and system hardware.
READ MORE - Configure the screen saver timeout in Windows Server 2008 Core Edition