Posted on Mon, Mar 01, 2010 @ 09:33 AM
In an organization with many computers, you probably won't want to apply security policy to each computer separately. You may want to apply security policies through Group Policy, and you may want to create computer OUs for this purpose.
Once you've created the necessary OUs, you can use the transform command in the Scwcmd utility to create a GPO that includes the settings in the security policy (and any security templates attached to the policy). You can then deploy the settings to computers by linking the new GPO to the appropriate OU or OUs.
Use the following syntax to transform a security policy: scwcmd transform /p:FullFilePathToSecurityPolicy /g:GPOName
Here, FullFilePathToSecurityPolicy will be the full file path to the security policy's .xml file and GPOName will be the display name for the new GPO. For example:
scwcmd transform /p:"c:\users\wrs\documents\fspolicy.xml" /g:"FileServer GPO"
When you've create the GPO, you can link the GPO to by following these steps:
1. In the GPMC, select the OU you want to work with. In the right pane, the Linked Group Policy Objects tab shows the GPOs that are currently linked to the selected OU (if any).
2. Right-click the OU to which you want to link the previously created GPO, and then select "Link an Existing GPO". In the Select GPO dialog box, select the GPO you want to link to, and then click OK.
3. When Group Policy is refreshed for computers in the applicable OU, the policy settings in the GPO are applied.
Because you've created a new GPO and then linked the GPO to the appropriate level in the Active Directory structure, you can recover the computers to their original state by removing the link to the GPO. To remove a link to a GPO, follow these steps:
1. In the GPMC, select and then expand the OU you want to work with. In the right pane, the Linked Group Policy Objects tab shows the GPOs that are currently linked to the selected OU.
2. Right-click the GPO. On the shortcut menu, the Link Enabled option should have a checkmark to show it is enabled. Clear this option and remove the link
Posted on Tue, Feb 23, 2010 @ 05:16 PM
Upgrading Exchange Address Lists as part of a transition/migration to Exchange Server 2007
Part of the transition/migration process to Exchange Server 2007 (probably one of the last steps) is to upgrade the default Address Lists, since OPATH filtering syntax replaces the LDAP filtering syntax. Here are the necessary PowerShell commands:
All Users
Set-AddressList "All Users" -IncludedRecipients MailboxUsers
All Groups:
Set-AddressList "All Groups" -IncludedRecipients MailGroups
All Contacts:
Set-AddressList "All Contacts" -IncludedRecipients MailContacts
Public Folders:
Set-AddressList "PublicFolders" -RecipientFilter { RecipientType -eq 'PublicFolder' }
Default Global Address List:
Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}
Posted on Tue, Feb 23, 2010 @ 05:05 PM
Moving Exchange Server 2007 Transport logs to a new location
Exchange Server 2007 registers most of its activity in specific logs that can be later analyzed for troubleshooting, forensic analysis or just to gather statistical information. The transport logs are very useful for any of the purposes previously mentioned, but since the volume of data written to disk can be quite large, it's a good practice to relocate these logs (the default path is C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs).
Here's a list of the necessary PowerShell cmdlets:
Set-TransportServer -Identity: -ReceiveProtocolLogPath
Set-TransportServer -Identity: -SendProtocolLogPath
Set-TransportServer -Identity: -MessageTrackingLogPath
Set-TransportServer -Identity: -RoutingTableLogPath
Posted on Tue, Feb 23, 2010 @ 04:24 AM
The Event Viewer automatically creates several filtered views of the event logs. Filtered views are listed under the Custom Views node. When you select the Administrative Events node, you see a list of all errors and warnings for all logs. When you expand the Server Roles node and then select a role-specific view, you see a list of all events for the selected role.
You can also create a custom view to make it easier to look for specific types of events. To do so, follow these steps:
1. In Server Manager, expand the Diagnostics node and the Event Viewer node.
2. Select Custom Views. In the actions pane or on the Action menu, click Create Custom View.
3. Use the Logged list to select the included time frame for logged events. You can choose to include events from the Last Hour, Last 12 Hours, Last 24 Hours, Last 7 Days, or Last 30 Days.
4. Use the Event Level check boxes to specify the level of events to include. Select Verbose to get additional detail.
5. You can create a custom view for either a specific set of logs or a specific set of event sources:
- Use the Event Logs list to select event logs to include. You can select multiple event logs by selecting their related check boxes. If you select specific event logs, all other event logs are excluded.
- Use the Event Sources list to select event sources to include. You can select multiple event sources by selecting their related check boxes. If you select specific event sources, all other event sources are excluded.
6. Optionally, use the User and Computer(s) boxes to specify users and computers that should be included. If you do not specify the users and computers to include, events generated by all users and computers are included.
7. When you click OK, Windows displays the Save Filter To Custom View dialog.
8. Type a name and description for the custom view.
9. Select where to save the custom view. By default, custom views are saved under the Custom Views node. You can create a new node by clicking New Folder, entering the name of the new folder, and then clicking OK.
10. Click OK to close the Save Filter To Custom View dialog box. You should now see a filtered list of events. Review these events carefully and take steps to correct any problems that exist.
If you want to see a particular type of event, you can filter the log by following these steps:
1. In Server Manager, expand the Diagnostics node and the Event Viewer node.
2. Expand Windows Logs or Applications And Services Logs as appropriate for the type of log you want to configure. You should now see a list of event logs.
3. Select the log you want to work with. In the actions pane or on the Action menu, click Filter Current Log.
4. Use the Logged list to select the included time frame for logged events. You can choose to include events from the Last Hour, Last 12 Hours, Last 24 Hours, Last 7 Days, or Last 30 Days.
5. Use the Event Level check boxes to specify the level of events to include. Select Verbose to get additional detail.
6. Use the Event Source list to select event sources to include. If you select specific event sources, all other event sources are excluded.
7. Optionally, use the User and Computer(s) boxes to specify users and computers that should be included. If you do not specify the users and computers to include, events generated by all users and computers are included.
8. Click OK. You should now see a filtered list of events. Review these events carefully and take steps to correct any problems that exist. To clear the filter and see all events for the log, click Clear Filter in the actions pane or on the Action menu.
Posted on Tue, Feb 23, 2010 @ 04:19 AM
Create Shadow Copies:
To create a shadow copy on an NTFS volume with shared folders, follow these steps:
1. Start Computer Management. If necessary, connect to a remote computer.
2. In the console tree, expand Storage and then select Disk Management. The volumes configured on the selected computer are displayed in the details pane.
3. Right-click Disk Management, point to All Tasks, and then select Configure Shadow Copies.
4. On the Shadow Copies tab, select the volume you want to work within the "Select A Volume" list.
5. Click Settings to configure the maximum size of all shadow copies for this volume and to change the default schedule. When you're finished, click OK twice.
6. If necessary, click Enable after you've configured the volume for shadow copying. When prompted to confirm this action, click Yes. This creates the first shadow copy and sets the schedule for later shadow copies.
Note that if you create a run schedule when configuring the shadow copy settings, shadow copying is enabled automatically for the volume when you click OK to close the Settings dialog box.
Restore Shadow Copies:
Users on client computers access shadow copies of individual shared folders using the Previous Versions or Shadow Copy client. The best way to access shadow copies on a client computer is to follow these steps:
1. Right-click the share for which you want to access previous file versions, choose Properties and then click the Previous Versions tab.
2. Then select the folder version that you want to work with. Each folder has a date and time stamp.
3. Then click the button corresponding to the action you want to perform:
- Click Open to open the shadow copy in Windows Explorer
- Click Copy to display the Copy Items dialog box, which lets you copy the snapshot image of the folder to the location you specify.
- Click Restore to roll back the shared folder to its state at the time of the snapshot image you selected.
Posted on Tue, Feb 23, 2010 @ 04:12 AM
The mechanism to create and manage Failover clusters is the Cluster Administrator application, part of the Administrative Tools folder.
To create a new Failover cluster, follow these steps.
(Note that the first three steps must be performed on all nodes that will be part of the Failover cluster.)
1. Open Windows Server 2008 Server Manager from the Administrative Tools folder.
2. Select Features in the left pane and click Add Features in the right pane.
3. Select Failover Clustering in the left pane and click Next.
4. Open Failover Cluster Management from the Administrative Tools folder. In the center pane, click Validate A Configuration from the Management section.
5. On the first screen of the Validate A Configuration Wizard, enter the network name of each node. You should select all of the nodes that are available to ensure that your testing validation is as accurate as possible.
6. Click Next to show the Testing Options page. You should run all tests to ensure that you fully test your configuration. If you are running the validation process of failing a previous validation, you can run only the tests that were not successful earlier.
7. Click Next to verify the tests to be performed. Once the tests are completed, the Summary page will indicate whether the tests were successful and whether the configuration is suitable to use as a Failover cluster.
8. Click Finish to end the Validate A Configuration Wizard. If errors were reported, fix the problems indicated and run the wizard again. If the validation was successful, click Create A Cluster in the Failover Cluster Management window.
9. Once the Create Cluster Wizard starts, you need to enter the names of the nodes that will be used to form the cluster. These should be the same nodes you entered previously during the validation process.
10. Click Next to proceed to the Access Point For Administering The Cluster page. On this page you need to enter the cluster name and IP address that will be used to identify and administer the cluster once it is created. The cluster name and IP address will be the virtual name registered in DNS and will be used to connect and manage the cluster itself. This information is usually different than the name and IP address that will be used by clients to connect to clustered applications.
11. Click Next to validate the settings and proceed to the Confirmation page. Ensure that all the information is accurate for the creation of the cluster. If not, click Previous to go back and change the settings. Otherwise, click Next to proceed to the cluster creation page.
At the completion of the cluster creation process, the Summary page will show you the results. If there were no errors, cluster was successfully formed. If there were any errors, click the View Report button to get details.
12. Click Finish to exit the wizard.
Posted on Mon, Feb 22, 2010 @ 10:10 AM
Reasons for this include but are not limited to:
- We run out of disk space and want to move it away from the system disk
- We want the DB to run on a faster/more reliable hard disk (other than the system disk)
- We experience performance issues and want to seperate the DB from the core OS hard disk
- We fat-fingered the correct location of the DB file when running dcpromo to bring the DC up
The discussion brought up a few funny suggestions on how to go about that (including simply "copy and paste" the files - at least they thought about booting in DS restore mode). So here's the outline how to do it with 2000 server and Server 2003.
1. Boot into Directory Services Restore Mode (DSRM) by pressing F8 on DC reboot. That's right, moving the database involves downtime.
2. Start ntdsutil in a CMD.
3. Enter the "File maintenance" submenu by typing "files".
4. Move the database to a new place by typing "move db to " where location is a path, similar to E:\NTDS\. Note that we don't have to specify the file name - just the folder ntdsutil shall copy the files to.
5. Move the log files to a new place place by typing "move logs to " where location is - again - a path like E:\NTDS. This is optional, but I'd keep the transaction log files with the database.]
6. Check whether the new file location is correct, typing "info" (still in the file maintenance submenu. Give it a go. If we've fat-fingered it once, changes are we did twice. The "info" command also prints out where all files are stored; database and log files and how much space they need.)
7. Check integrity of the database after it has moved. Do so by typing "integrity". This step might take a few minutes depending on how large wer database is - but since wer down anyway, we should take the time to ensure everything is correct.
8. Type "quit" twice and close the cmd. Now boot into normal mode again.
9. It is recommended that we back up the system state to have a current backup of the database now (it is a good thought to have a backup anyway since we clean-booted the DC and have it check for integrity. Another aspect is that when restoring an older system state, the location previous location of the NTDS.dit will be used - we'd have to move the NTDS.dit once again using ntdsutil.
Please don't forget to check security on the folder we move the database to. It's a bad idea to move it into a shared folders or the wwwroot. We may laugh and I must admin those two examples are a bit of extreme. The point is that we should take a moment and review the NTFS permissions of the DB folder. Don't share it, don't allow anyone to access it.
Windows Server 2003
Account Permissions Inheritance
System Full Control This folder, subfolders and files
Administrators Full Control This folder, subfolders and files
Creator Owner Full Control Subfolders and Files only
Local Service Create Folders / Append Data This folder and subfolders
Windows 2000
Account Permissions Inheritance
Administrators Full Control This folder, subfolders and files
System Full Control This folder, subfolders and files
A Windows Server 2008's NTDS.dit location can be changed this way (it differs as Windows Server 2008 has the capability of stopping Active Directory and its services temporarily. This wasn't possible with before 2008):
1. Stop the "Active Directory Domain Services" service in services.msc. It will prompt we that it'll need to shut down other services as well (Kerberos, File Replication, DNS, ..). We want these services to stop, too, so click "Yes".
2. Open ntdsutil. We need to activate the correct instance of ntds to perform maintenance tasks. The standard instance of Active Directory is "ntds", so we use "activate instance ntds" as the first command.
3. Enter the File maintenance submenu by typing "files" as the second command.
4. Move the database to a new place by typing "move db to " where location is a path, similar to E:\NTDS\. Note that we don't have to specify the file name - just the folder ntdsutil shall copy the files to.
5. Move the log files to a new place place by typing "move logs to " where location is - again - a path like E:\NTDS. This is optional, but I'd keep the transaction log files with the database.]
6. Check whether the new file location is correct, typing "info". ("info" also prints out where all files are stored; database and log files and how much space they need.)
7. Check integrity of the database after it has moved. Do so by typing "integrity". This step might take a few minutes depending on how large wer database is - but since wer down anyway, we should take the time to ensure everything is correct.
8. Type "quit" twice and close the cmd. Start the "Active Directory Domain Services" service again.
9. Backup the system state. See above for reasons.
Just like with Server 2003 and 2000, check the security on the folder we move the DB. Since I haven't found documentation that tells otherwise, I guess the permissions in Server 2003 are good for 2008 too.
Posted on Mon, Feb 22, 2010 @ 08:03 AM
Full server and server core installations are different when it comes to local console administration. With a full server installation, we have a UI that includes a full desktop environment for local console management of the server. With a core server installation, we have a minimal UI that includes a limited desktop environment for local console management of the server. This minimal interface includes:
- Windows Logon screen for logging on and logging off
- Notepad for editing files
- Regedit for managing the registry
- Task Manager for managing tasks and starting new tasks
- Command Prompt for administration via the command line
After we log on to a core-server installation, we have a limited desktop environment with an Administrator command prompt. we can use this command prompt for administration of the server. If we accidentally close the command prompt, we can start a new command prompt by following these steps:
1. Press Ctrl+Shift+Esc to display Task Manager.
2. On the Applications tab, click New Task.
3. In the Create New Task dialog box, type cmd in the Open field and then click OK.
We can start Notepad and Regedit directly from a command prompt by entering notepad.exe or regedit.exe as appropriate. To open Control Panel, type intl.cpl.
At the command prompt, we'll find that you have all the standard commands and command-line utilities available for managing the server. However, keep in mind that commands, utilities, and programs will only run if all of their dependencies are available in the core-server installation.
While core-server installations support a limited set of roles and role services, we can install most features. The key exceptions are those that depend on the .NET Framework. Because the Microsoft .NET Framework is not supported in the original implementation, we cannot add features such as Windows PowerShell. And we can use Terminal Services to manage a core-server installation remotely.
Here is an overview of key commands and utilities we'll use for managing server core installations while logged on locally:
Control desk.cpl - View or set display settings.
Control intl.cpl - View or set regional and language options, including formats and the keyboard layout.
Control sysdm.cpl - View or set system properties.
Control timedate.cpl - View or set the date, time, and time zone.
Cscript slmgr.vbs -ato - Activate the operating system.
DiskRaid.exe - Configure software RAID.
ipconfig /all - List information about the computer's IP address configuration.
NetDom RenameComputer - Set the server's name and domain membership.
OCList.exe - List roles, role services, and features.
OCSetup.exe - Add or remove roles, role services, and features.
PNPUtil.exe - Install or update hardware device drivers.
Sc query type=driver - List installed device drivers.
Scregedit.wsf - Configure the operating system. Use the /cli parameter to list available configuration areas.
ServerWerOptin.exe - Configure Windows Error Reporting.
SystemInfo - List the system configuration details.
WEVUtil.exe - View and search event logs.
Wmic datafile where name="FullFilePath" get version - List a file's version.
Wmic nicconfig index=9 call enabledhcp - Set the computer to use dynamic IP addressing rather than static IP addressing.
Wmic nicconfig index=9 call enablestatic("IPAddress"), ("SubnetMask") - Set a computer's static IP address and network mask.
Wmic nicconfig index=9 call setgateways("GatewayIPAddress") - Set or change the default gateway.
Wmic product get name /value " - List installed MSI applications by name.
Wmic product where name="Name" call uninstall - Uninstall an MSI application.
Wmic qfe list - List installed updates and hotfixes.
Wusa.exe PatchName.msu /quiet - Apply an update or hotfix to the operating system.
Posted on Mon, Feb 22, 2010 @ 03:14 AM
In Windows Server 2008, you can now set up AD DS (Active Directory Domain Services) auditing with a new audit policy subcategory (Directory Service Changes) to log old and new values when changes are made to AD DS objects and their attributes.
However Directory Services depends on several controls to be implemented:
1. Global Audit Policy (at category level)
2. Individual Audit Policy (at subcategory level)
3. System ACLs
4. Schema (optional)
1. Global Audit Policy
The global audit policy "Audit directory service access" (from the default Domain Controllers Policy) controls whether auditing for directory service events is enabled or disabled.
2. Individual Audit Policy
Use the command-line tool Auditpol.exe to view or set audit policy subcategories. There is no Windows interface tool available in Windows Server 2008 to view or set audit policy subcategories, not even with the Group Policy Object Editor (GPedit.msc).
Is the auditpol.exe tool new?? Of course not... it already existed since Windows NT4 as part of the Resource Kit (Supplement 2). However, one important option is missing... you can no longer change audit polices remotely as you could before...
To enable "Directory Service Changes", type:
auditpol /set /subcategory:"directory service changes" /success:enable
When enabling "Directory Service Changes" events are logged in the Security event log when changes are made to objects that an administrator has set up for auditing using an SACL. These eventids will appear: 5136 (Modify), 5137 (Create), 5138 (Undelete), 5139 (Move). The "Delete" operation is not part of "DS Changes", but rather "DS Access".
3. System ACLs (SACLs)
The SACL (System Access Control List) is the part of an object's security descriptor that specifies which operations are to be audited for a security principal. The SACL on the object is still the ultimate authority in determining whether an access check must be audited or not.
If there is no access control entry (ACE) in the SACL requiring attribute modifications to be logged, even if the Directory Service Changes subcategory is enabled, no change auditing events are logged.
The content of the SACL is controlled by "security administrators" for the local system. Security administrators are users who have been assigned the "Manage Auditing and Security Log" (SeSecurityPrivilege) privilege. By default, this privilege is assigned to the built-in Administrators group.
4. Schema
To avoid the possibility of an excessive number of events being generated, there is an additional control in the schema that you can use to create exceptions to what is audited.
For example, if you want to see changes for all attribute modifications on a user object - except for one or two attributes, you can set a flag in the schema for the attributes that you do not want audited. The searchFlags property of each attribute defines whether the attribute is indexed, replicated to the global catalog, or some other such behavior.
If bit 9 (value 256) is set for an attribute, AD DS will not log change events when modifications are made to these attribute. Do understand, this applies to all objects/classes that contain that attribute.
To finish up, how can you find out which audit policies are active on your machine?
auditpol /get /category:*
Posted on Mon, Feb 22, 2010 @ 02:25 AM
Wbadmin is the command-line counterpart to Windows Server Backup. We use Wbadmin to manage all aspects of backup configuration that you would otherwise manage in Windows Server Backup. This means that you can typically use either tool to manage backup and recovery.
After you've installed the Backup Command-Line Tools feature, you can use Wbadmin to manage backup and recovery. Wbadmin is located in the %SystemRoot%\System32\ directory. As this directory is in your command path by default, you do not need to add this directory to your command path.
You can run Wbadmin by following these steps:
1. Click Start, click All Programs, and then click Accessories to open the Accessories menu.
2. Start an elevated command prompt by right-clicking Command Prompt and then selecting Run As Administrator.
3. In the Command Prompt window, enter the necessary command text or run a script that invokes Wbadmin.
Wbadmin has a number of associated commands:
DELETE SYSTEMSTATEBACKUP Deletes the system state backup or backups from a specified location.
DISABLE BACKUP Disables scheduled daily backups so that they no longer run.
ENABLE BACKUP Enables or modifies a scheduled daily backup.
GET DISKS Lists the disks that are currently online for the local computer. Disks are listed by manufacturer name, type, disk number, GUID, total space, used space, and associated volumes.
GET ITEMS Lists items contained in a specified backup.
GET STATUS Reports the status of the currently running backup or recovery job.
GET VERSIONS List details about the available backups stored in a specific location, including the backup time and backup destination.
START BACKUP Starts a one-time backup using the specified parameters. If no parameters are passed and scheduled backups are enabled, the backup uses the settings for scheduled backups.
START RECOVERY Initiates a recovery of volumes, applications, or files using the specified parameters.
START SYSTEMSTATEBACKUP Starts a system state backup using the options specified.
START SYSTEMSTATERECOVERY Starts a system state recovery using the specified parameters.
STOP JOB Stops the currently running backup or recovery job. Stopped jobs cannot be restarted from where they were stopped.
When you are working with Wbadmin, you can get help on available commands:
1.To view a list of management commands, type wbadmin /? at the command prompt.
2.To view the syntax for a specific management command, type wbadmin Command /?, where Command is the name of the management command you want to examine, such as wbadmin stop job /?.
When you work with Wbadmin, you'll find that just about every command accepts parameters and specific parameter values that qualify what you want to work with. To see more clearly how this works, consider the following syntax example:
wbadmin get versions [-backupTarget:{VolumeName | NetworkSharePath}]
[-machine:BackupMachineName]
The brackets tell you that -backupTarget and -machine are optional. Thus, you could type the following to get information on recoverable backups on the local computer:
wbadmin get versions
You could type the following to get information on recoverable backups for C:
wbadmin get versions -backuptarget:f:
Or you could type the following to get information on recoverable backups for C on Server96:
wbadmin get versions -backuptarget:f: -machine:servername
Many Wbadmin commands use the -backupTarget and -machine parameters. The backup target is the storage location you want to work with, and can be expressed as a local volume name ( such as F: ) or as a network share path, such as \\FileServer\backups\Servername. The -machine parameter identifies the computer you want to work with for backup or recovery operations.