How To Backup/Restore An Active Directory Integrated DNS Zone

Whenever you make a fundamental change to a DNS zone it’s a good idea to back it up, but how do you do that when your DNS is Active Directory Integrated without taking a system state backup? We’ll take a look at both AD integrated and standalone methods to get a better understanding.

Non-AD integrated (Standalone) DNS:

If you’re running standalone DNS and simply have a Primary/Secondary setup then performing this style of backup is really very simple.  As standard DNS zone file information is stored in the %systemroot%\system32\dns folder (typically C:\Windows\System32\dns). When the DNS service starts it simply loads the dones from these files, likewise when a change is made it creates a backup and places it in the backup folder on the aforementioned path. It’s worth noting that only one backup is maintained so if you make another change the previous backup is overwritten, therefore if you make a sideways copy of these backups you can keep a version as long as you need.

AD Integrated Zones:

As AD integrated zones are stored within the Active Directory they do not have  any files associated with them and therefore are not backed up to the backup directory. So how do we get it out? Using DnsCmd.exe is how!

The Microsoft example of a zone export is as follows:

dnscmd [] /zoneexport 

This looks great but here it is in a more useful looking format:

DnsCmd DNSserver1 /ZoneExport example.com example.com.bak

Note that the backup file you have created will land in %systemroot%\System32\dns

How to restore AD Integrated Zones:

Warning: You should only attempt to restore this file as a last resort as it could impact your users especially then allowing for replication to the DNS holding DC’s.

  • Hop onto the DNS Management Console and delete the zone
  • Rename your zone backup to have a .dns extension, in the example above this would go from example.com.bak to example.com.dns
  • Create a new zone with the FQDN of the zone you deleted, if using the New Zone Wizard be sure to uncheck the Store in Active Directory option.
  • When prompted to create a new zone file or use an existing file, choose an existing file, the wizard should automatically fill in the zone FQDN with the .dns extension, this should look the same as your renamed zone file (example.com.dns)
  • Complete the wizard
  • Check the zone information is as per the zone before the changes
  • If all is well, simply change the zone type to Active Directory Integrated.

Job done.

Advertisements

How To Find Your Local NTP Server

So, you get on site and no one knows where their NTP server is, there’s a quick and easy way to find out.

The old schoolers will tell you to use the net time commmand, but this was deprecated and is no longer recommended for use by Microsoft.

If you still want to use it or you’re on a Windows Server 2000 box

  • Open up a command prompt
  • Type: net time /query \\serveryouwanttoquery

If you’re on anything newer:

  • Open up a command prompt
  • Type: w32tm /query /computer:computeryouwanttoquery /source
  • If you’re having trouble w32tm.exe is found in “C:\Windows\System32″.

W32tm.exe is a powerful little tool that not only allows you to check the basic status but also completely configure the NTP server/service to whatever your heart desires. For more, check out this technet article over at the Microsoft site.

 

This blog was copied from: http://sysbadmin.wordpress.com/2012/09/27/how-to-find-your-local-ntp-server/

 

Practical tips on simplifying GPOs and OU organization

Practical tips on simplifying GPOs and OU organization

Summary: Deep paths within Active Directory can complicate Organizational Units and Group Policy Objects organization. IT pro Rick Vanover shares his approach to managing the complexity of GPOs.

One of the most powerful centralized administration tasks for Windows Servers and PCs is deploying Group Policy Objects (GPOs). So much so, in fact, that I could argue Group Policy is one of the best solutions Microsoft has ever provided.

While I’m very fond of GPOs and their flexibility to configure user and computer settings centrally, we can easily get out of control with conflicting rules and overly complicated implementations. I’m sure we’ve all seen a domain that has a very ugly configuration of GPOs, and let’s not even get started on the security groups.

In my Active Directory practice, I go back and forth in determining how deep the GPOs and Organizational Units (OUs) should go. I frequently don’t do more than three GPOs flowing in series with the OUs.

By series I mean one GPO in a parent OU and another GPO in a child OU, like Figure A where the green GPO applies to the parent OU and the red GPO applies to the child OU (as well as the green GPO).

Figure A

Click the image to enlarge.

OUs are great for granular classification of various Active Directory objects, though I don’t really have an incredible issue going very deep (within reason) in terms of levels for this configuration. GPOs, on the other hand, are not good candidates for multiple applications for each OU as the tree goes deeper.

It is too complicated to keep the configuration rules in mind for planning and quick thinking. To help simplify how GPOs are organized, here are some tips:

  • Leverage GPO filtering by security group to make more GPOs at a higher OU instead of more GPOs in deeper OUs
  • Never add individual users or computer accounts (always use the group trick above)
  • Combine user and computer settings by role, rather than separate GPOs
  • Self-document the names of the GPOs to be intuitive to the role and location
  • Use a consistent GPO nomenclature, including renaming GPOs to get there
  • Scour around for GPOs that have one setting and consolidate it with other GPOs

GPOs are great, but the tools require organization and thought. These tips are general guidelines, and any of you keeping score will note that my screenshot from my personal lab is not exactly following all of these recommendations. It’s fine for a lab, but in production, that’s a different story.

Rick Vanover is an IT infrastructure manager for a financial services organization in Columbus, Ohio. He has years of IT experience and focuses on virtualization, Windows-based server administration and system hardware.

Also read:

 

Configure server, desktop, laptop power options with Group Policy

Disable Server Manager and Initial Configuration Tasks via Group Policy

Logon Scripts on a Windows Server

Logon Scripts Concepts

http://technet.microsoft.com/en-us/library/cc740163(v=ws.10)

 

Assign a logon script to a user or group

http://technet.microsoft.com/en-us/library/cc784088(v=ws.10)

 

Understanding logon scripts

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

Understanding logon scripts

A logon script runs automatically whenever a user logs on to a computer running a member of the Windows Server 2003 family of operating systems. The script can contain operating system commands, such as those that make network connections or start programs. Logon scripts can also set environment variables to specify information such as the computer search path and the directory for temporary files. A logon script is usually a batch file (.bat or .cmd file name extension), but any executable program can be used.

Logon scripts are optional. You can use them to configure user working environments by creating network connections and starting programs. Logon scripts are useful when you want to affect the user work environment without managing all aspects of it.

Script files are text files that contain script commands. The Windows Server 2003 family of operating systems supports these types of scripts:

  • Batch file commands are stored in text files with the .bat or .cmd file name extension. Batch files automate simple series of tasks that would otherwise be run from a command line. Scripts written using batch file commands are run by the command shell. For more information about the command shell, see Command shell overview.
  • Visual Basic Scripting Edition (VBScript) commands are stored in text files with the .vbs file name extension, and JScript commands are stored in text files with the .js file name extension. VBScript and JScript allow the administrator to construct sophisticated scripts. The Windows Script Host can run these scripts from the desktop of the computer, or from a command line. For more information about the Windows Script Host, see Windows Script Host.

After you create a logon script, you can assign it to one or more local users, sites, domains, or organizational units (OUs).

For more information about specific tasks related to assigning scripts, see Logon Scripts How To….

 

 

 

 

 

Logon script assignment

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

Logon script assignment

On computers running operating systems in the Windows Server 2003 family, you can assign a logon script to a user account. When a user logs on and a path to a logon script is present in the user account, the file is located and run.

You can also assign logon and logoff scripts, and computer startup and shutdown scripts by using the Group Policy snap-in. These scripts apply to the entire scope of users and computers for which a particular Group Policy object applies.

In Computer Management, you can use the User Property dialog box to assign logon scripts to user accounts by typing the file name (for example, Clerks.bat) in the Logon script text box. At logon, the server authenticating the logon locates an assigned logon script. It looks for the specified file following the local logon script path on the server (usually %systemroot%\SYSVOL\sysvol\domain_name\scripts). If a relative path is provided before the file name (for example, Admins\User1.bat), the server looks for the logon script in that subdirectory of the logon script path.

The entry in the Logon Script text box specifies only the file name (and, optionally, the relative path) and does not create the actual logon script. You create a logon script with the specified name and place it in the appropriate directory on the appropriate replication export server.

You can place a logon script in a local directory on a user’s computer. You would typically use this location, however, when you are administering user accounts that exist on a single computer rather than in a domain. This logon script runs only when a user logs on locally to the computer and does not run when the user logs on to the domain. You must place the logon script using the computer’s logon script path or in a subdirectory of that logon script path. The default location for local logon scripts is the %systemroot%\System32\Repl\Imports\Scripts folder. This folder is not created on an new installation of Windows XP. A folder must be created and shared with the name netlogon; for step-by-step instructions, see Share a folder or drive. The NTFS permissions of this folder should allow users and server operators only read and execute permissions, and should allow administrators full control. The folder is created and shared automatically on domain controllers, so you should not attempt to create a netlogon folder on a domain controller manually.

For more information, see: Logon Scripts How To…Group Policy overview, and Privileges.

 

 

 

 

 

Creating logon scripts

http://technet.microsoft.com/en-us/library/cc758918%28WS.10%29.aspx

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

Creating logon scripts

You can use logon scripts to assign tasks that will be performed when a user logs on to a particular computer. The scripts can carry out operating system commands, set system environment variables, and call other scripts or executable programs. The Windows Server 2003 family supports two scripting environments: the command processor runs files containing batch language commands, and Windows Script Host (WSH) runs files containing Microsoft Visual Basic Scripting Edition (VBScript) or Jscript commands. You can use a text editor to create logon scripts. Some tasks commonly performed by logon scripts include:

  • Mapping network drives.
  • Installing and setting a user’s default printer.
  • Collecting computer system information.
  • Updating virus signatures.
  • Updating software.

The following example logon script contains VBScript commands that use Active Directory Service Interfaces (ADSI) to perform three common tasks based on a user’s group membership:

  1. It maps the H: drive to the home directory of the user by calling the WSH Network object’s MapNetworkDrive method in combination with the WSH Network object’s UserName property.
  2. It uses the ADSI IADsADSystemInfo object to obtain the current user’s distinguished name, which in turn is used to connect to the corresponding user object in Active Directory. Once the connection is established, the list of groups the user is a member of is retrieved by using the user’s memberOf attribute. The multivalued list of group names is joined into a single string by using VBScript’s Join function to make it easier to search for target group names.
  3. If the current user is a member of one of the three groups defined at the top of the script, then the script maps the user’s G: drive to the group shared drive, and sets the user’s default printer to be the group printer.

To create an example logon script

  1. Open Notepad.
  2. Copy and paste, or type, the following:
    Const ENGINEERING_GROUP     = "cn=engineering"
    Const FINANCE_GROUP         = "cn=finance"
    Const HUMAN_RESOURCES_GROUP = "cn=human resources"
    
    Set wshNetwork = CreateObject("WScript.Network")
    wshNetwork.MapNetworkDrive "h:",
    "\\FileServer\Users\" & wshNetwork.UserName
    
    Set ADSysInfo = CreateObject("ADSystemInfo")
    Set CurrentUser = GetObject("LDAP://" &
    ADSysInfo.UserName)
    strGroups = LCase(Join(CurrentUser.MemberOf))
    
    If InStr(strGroups, ENGINEERING_GROUP) Then
    
        wshNetwork.MapNetworkDrive "g:",
        "\\FileServer\Engineering\"
        wshNetwork.AddWindowsPrinterConnection
        "\\PrintServer\EngLaser"
        wshNetwork.AddWindowsPrinterConnection
        "\\PrintServer\Plotter"
        wshNetWork.SetDefaultPrinter
        "\\PrintServer\EngLaser"
    
    ElseIf InStr(strGroups, FINANCE_GROUP) Then
    
        wshNetwork.MapNetworkDrive "g:",
        "\\FileServer\Finance\"
        wshNetwork.AddWindowsPrinterConnection
        "\\PrintServer\FinLaser"
        wshNetWork.SetDefaultPrinter
        "\\PrintServer\FinLaser"
    
    ElseIf InStr(strGroups, HUMAN_RESOURCES_GROUP) Then
    
        wshNetwork.MapNetworkDrive "g:",
        "\\FileServer\Human Resources\"
        wshNetwork.AddWindowsPrinterConnection
        "\\PrintServer\HrLaser"
        wshNetWork.SetDefaultPrinter
        "\\PrintServer\HrLaser"
    
    End If
    
  3. On the File menu, click Save As.
  4. In Save in, click the directory that corresponds to the domain controller’s Netlogon shared folder (usuallySystemRoot\SYSVOL\Sysvol\DomainName\Scripts where DomainName is the domain’s fully qualified domain name).
  5. In Save as type, click All Files.
  6. In File name, type a file name, followed by .vbs, and then click Save. WSH uses the .vbs extension to identify files that contain VBScript commands.

Notes

  • To open Notepad, click Start, point to All programs, point to Accessories, and then click Notepad.
  • To use the example logon script, you need to change the group names, network drive letters, and Universal Naming Convention (UNC) paths to match your system environment.
  • To run a logon script, you need to assign the script to a user or a group. For more information, see Assign a logon script to a user or group.

For more information about creating and using logon scripts, see Logon Scripts, Windows Script at the Microsoft Web site, and theMicrosoft Windows Resource Kits Web site.

Information about functional differences

  • Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings. For more information, see Viewing Help on the Web.

 

 

 

 

 

 

 

 

Using Logon Scripts in Pure and Mixed Active Directory Environments

This article looks at the differences in implementing logon scripts in pure and mixed Active Directory environments, including how to use Group Policy to assign scripts and how to run Windows Script Host (WSH) scripts from batch files.


Logon scripts can be useful tools for configuring desktop environments for users. Some of the things such scripts can be used for include mapping network drives, connecting to shared printers, gathering system information, synchronizing system clocks, and so on. In fact, just about anything you can do from the command-line can be done using a logon script.

Logon scripts have been around for a while and most administrators of Windows-based networks have had occasion to use them. On Windows NT domain-based networks things were simple: if a user needed to have his environment configured using a logon script, the administrator would first write a logon script using the batch programming language, which has been around since the days of MS-DOS. Once written, this script was saved using a .bat extension to make it executable, but to make it work for a particular user the script needed to be found in the NETLOGON share of the domain controller to which the user’s account was authenticated. In Windows NT this NETLOGON share corresponded to the %systemroot%\system32\repl\import\scripts folder, and by placing the script in this folder on the PDC it was automatically replicated to all BDC’s in the domain. Once this was done, the administrator only had to add the name of the script to the Logon Script Name field on the User Environment Profile dialog box using User Manager for Domains.

Then Windows 2000 came along, with its support for assigning logon scripts using Group Policy and its built-in support for Windows Script Host (WSH) as an alternative for traditional batch scripts. While WSH lets you create much more powerful logon scripts and Group Policy lets you manage logon scripts more easily, a problem arises when your networking environment has a mix of desktops that include legacy platforms like Windows 95/98 and Windows NT 4.0 Workstation. The rest of this article provides some suggestions for managing logon scripts in both a mixed (Windows 2000/XP/2003 and legacy Windows 95/98/NT) environment and a pure Windows 2000 (or later) environment. 

Using Logon Scripts in a Mixed Environment

By “mixed environment” I mean a mixture of Windows clients that support Group Policy (Windows 2000/XP/2003) and those that don’t (Windows 95/98/NT). Managing logon scripts in environments that include Linux/UNIX or Mac desktops is beyond the scope of this discussion. For simplicity, we’ll focus here on Active Directory environments that have domain controllers running Windows 2000 Server and/or Windows Server 2003 and a mix of current and legacy Windows desktops.

Let’s say you want to use a logon script in a mixed environment to configure users’ desktop environments by mapping a drive letter to a network share. A simple batch file logon script that does this might be this:

        @echo off
        net use x: \\filesrv\budgets


To use this script, type it into Notepad and save it as logon.bat or something similar. Then put the script into the NETLOGON share on a domain controller, which if your domain controllers are running Windows 2000/2003 can be found at %systemroot%\sysvol\sysvol\<domain_DNS_name>\scrip ts as shown in Figure 1:

Posted Image

Figure 1: Location of NETLOGON share on Windows 2000/2003 domain controllers

Once this script is placed in the NETLOGON share it will automatically replicate to all domain controllers in the mynewforest.com domain.

The next step is to assign the logon script to the user accounts of users who need to have the script run on their desktop machines. To get the script to run on Bob Smith’s machine, for example, use Active Directory Users and Computers to open the Properties sheet for the User object representing Bob Smith and select the Profiles tab. Then simply type the name of the script in the Logon Script field as shown in Figure 2 below. Note that if you store your logon script in a different share than NETLOGON, you should type the full UNC path instead to the script in the Logon Script field below but make sure the script replicates to all your domain controllers.

Posted Image

    Figure 2: Assigning a logon script to user Bob Smith

If you want to leverage the power of Windows Script Host in a mixed environment, you can do so two ways:

    * Download and install the appropriate Directory Services Client (DSClient) for Windows 95/98 or Windows NT. DSClient allows these legacy Windows platforms to participate in an Active Directory environment and they include support for WSH and VBScript. To obtain DSClient for the appropriate platform, see article 288358 in the Microsoft Knowledge Base.
    * Download and install Windows Script Host for Windows 95/98/NT. Doing this lets you run VBScript scripts on these platforms, but it doesn’t give you ADSI functionality so this limits the usefulness of WSH for scripting purposes. You can obtain WSH for Windows 95/98/NT from the Microsoft Download Center.

Either way, once your legacy Windows desktops support WSH you can write your logon scripts in the more powerful VBScript language instead of the limited batch programming language. Unfortunately, in a mixed environment you can’t directly assign a .vbs script to a user account on the Profile tab as shown in Figure 2 above as this won’t work on legacy Windows clients. The workaround to this problem is to do the following:

   1. Write your logon script using VBScript and save it with a .vbs extension, for example logon.vbs.
   2. Store your logon.vbs file in the NETLOGON share on your domain controller.
   3. Use the batch programming language to write a traditional logon script that calls your logon.vbs script and save it with a .bat extension, for example logon.bat.
   4. Store your logon.bat file also in the NETLOGON share on your domain controller.
   5. Assign logon.bat on the Profile tab of each user account as described previously above in Figure 2.

A simple logon.bat script that calls a logon.vbs script would be the following:

        @echo off
        wscript %0\..\logon.vbs


And a simple logon.vbs script that maps the x: drive to the \\filesrv\budgets share would be:

        Dim wshNetwork
        Set wshNetwork = CreateObject("Wscript.Network")
        wshNetwork.MapNetworkDrive "x:", "\\filesrv\budgets"
        WSCript.Quit


Now when Bob logs on to his machine, logon.bat executes and calls logon.vbs which maps x: drive to the budgets share as desired. And this will work on both your legacy Windows 95/98/NT desktops and your newer Windows 2000/XP desktops. 

Using Logon Scripts in a Windows 2000 or Later Environment

If all your desktops are running Windows 2000 or later, then the first thing you should do is forget the Profile tab as far as logon scripts are concerned. In fact, forget the Profile tab entirely as the fields on this tab are provided only for downlevel (Windows NT or earlier) environments. Instead, use Group Policy to assign your logon scripts, which is a far more powerful and flexible approach than what the Profile tab provides. Furthermore, forget the batch programming language and use VBScript to write your logon scripts as this lets you create far more powerful scripts than batch scripts. If you haven’t yet learned VBScript, see the Resources section at the end of this article for some tutorials.
Let’s use our logon.vbs script above that maps a drive and assign it to all our company employees in Winnipeg. The beauty of Active Directory is that you can create organizational units (OUs) for different locations or departments in your company and then create Group Policy Objects (GPOs) and link them to each OU. In Figure 3 you can see that we have three OUs in our mynewforest.com domain: Toronto, Vancouver, and Winnipeg:

Posted Image

    Figure 3: Users in the Winnipeg OU need a logon script assigned to map a network drive

To assign logon.vbs to the users in Winnipeg, right-click on the Winnipeg OU and select Properties. Then select the Group Policy tab, where you can see we’ve already created a new GPO named WinnipegGPO and linked it to this OU (Figure 4):

Posted Image

    Figure 4: The WinnipegGPO is linked to the Winnipeg OU

Click Edit to open the WinnipegGPO and navigate to User Configuration\Windows Settings\Scripts as in Figure 5 below:

Posted Image

    Figure 5: Policy settings for assigning logon and logoff scripts

Now right-click on Logon in the right-hand pane and select Properties (Figure 6):

Posted Image

    Figure 6: Assigning a new logon script using the WinnipegGPO

Click the Show Files button to open the default folder where logon scripts assigned using Group Policy are stored on your domain controller (Figure 7):

Posted Image

    Figure 7: Default folder where logon scripts assigned using Group Policy are stored on a domain controller

Note from this figure that logon scripts assigned using Group Policy are stored in a subfolder of the SYSVOL share on your domain controllers. This subfolder of SYSVOL is named \sysvol\<domain_DNS_name>\<policy_GUID>\user\scrip ts\logon and the contents of this folder (being in SYSVOL) are automatically replicated to all domain controllers in the domain.
Now, using Windows Explorer, find the logon.vbs script we created earlier and press CTRL+C to copy it to the clipboard. Then return to the folder in Figure 7 above and press CTRL+V to copy logon.vbs into the folder where it needs to be. Close the folder window and return to the Logon Properties screen in Figure 6 previously and click the Add button to open the Edit Script dialog box, and in the Script Name field type logon.vbs, the name of the script you want to assign (Figure 8):

Posted Image

    Figure 8: Assign the logon script

Click OK twice and the script has been assigned. Now once Group Policy refreshes on Bob’s machine, the next time he logs on to his machine he’ll see X: drive when he opens My Computer or Windows Explorer.

Resources

If you want to learn how to start writing WSH scripts using VBScript, or find some useful scripts others have already developed, here are a few resources to check out:

    * Scripting on MSDN

http://msdn.microsoft.com/en-us/library/ms950396

    * Script Center on TechNet

http://technet.microsoft.com/de-de/scriptcenter/default.aspx

    * VBScript Primer

http://technet.microsoft.com/de-de/library/ee198896%28en-us%29.aspx

    * WSH Primer

http://technet.microsoft.com/en-us/library/ee156603.aspx

    * VBScript User’s Guide

http://msdn.microsoft.com/en-us/library/sx7b3k7y%28vs.71%29.aspx

    * VBScript Language Reference

http://msdn.microsoft.com/en-us/library/d1wf56tt%28vs.71%29.aspx

AD FS 2.0: Migrate Your AD FS Configuration Database to SQL Server

AD FS 2.0: Migrate Your AD FS Configuration Database to SQL Server

 

The AD FS configuration database stores all the configuration data that represents a single instance of AD FS 2.0 (also known as the Federation Service). You can store this configuration data in either a Microsoft SQL Server® database or using the Windows Internal Database. The Windows Internal Database is a Windows Server feature that is automatically installed on the computer whenever you complete the AD FS 2.0 Federation Server Configuration Wizard for the first time.

Since the wizard does not provide a UI option to choose SQL Server as the store for the AD FS configuration database it is understandable how many would continue to use the wizard defaults to see if it will work well for their infrastructure. It is highly possible that in time you may want to scale out your federation server farm to use more than 5 federation servers by migrating the configuration database to SQL Server. By migrating to SQL you will obtain scale, high availability and also be able to use SQL’s backup mechanisms.

This topic is provided for just this situation and will walk you through all the steps necessary to migrate your existing AD FS configuration data from your current Windows Internal Database store (in a production environment) to a new SQL Server store. Follow steps 1, 2, 3, and 5 on the primary federation server. Follow steps 1,2, 4 and 5 on each of the secondary federation servers in the farm. These steps include:

1.       Backing up the federation server

2.       Temporarily disable the computer in the load balancer

3.       Performing steps on the primary federation server

4.       Performing steps on all of the secondary federation servers

5.       Enabling the computer on the load balancer

For more information about the pros and cons of using either Windows Internal Database or SQL Server to store AD FS 2.0 configuration data, see The Role of the AD FS Configuration Database in the AD FS 2.0 Design Guide.

http://technet.microsoft.com/en-us/library/ee913581%28WS.10%29.aspx

Step 1: Backing up the federation server

Use Windows Server Backup to back up the entire federation server computer including the AD FS configuration database stored in Windows Internal Database. You can also use Windows Server Backup to restore the AD FS configuration database.

More information about how to backup the AD FS configuration database will be out soon. Once this content is provided we will update this link.

Step 2: Temporarily disable the computer in the load balancer

If your federation server is running in a farm and you have a load balancer, temporarily remove this machine from the load balancer configuration.

Step 3: Performing steps on the primary federation server

1.       On the primary federation server in the farm, download the SQL Server 2008 Management Studio Express software and install it on the primary federation server using this 

link http://www.microsoft.com/downloads/details.aspx?FamilyID=08e52ac2-1d62-45f6-9a4a-4b76a8564a2b&displaylang=en 

This software is necessary in order to install and register the sqlcmd command-line tool which is necessary in an upcoming step.

2.       Stop the AD FS 2.0 Windows Service on the primary federation server. Open an elevated command prompt, type the following command-line to stop the AD FS 2.0 Windows Service, and then press ENTER:

net stop adfssrv

3.       Connect to the Windows Internal Database that currently stores the AD FS configuration database and then detach both the AD FS configuration and artifact databases. In the command prompt window, type the following sqlcmd command-line syntaxes in order, and then press ENTER after each one.

sqlcmd -S \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

use master

go                

sp_detach_db 'adfsconfiguration'

go

sp_detach_db 'adfsartifactstore'

go

4.       Connect to SQL server and attach the configuration and artifact database from the primary federation server. In the command prompt window, type the following sqlcmd command-line syntaxes in order, and then press ENTER after each one. In SQLServer\SQLInstance below, type in the appropriate SQL Server and SQL Server instance name where you are migrating the configuration data to. For example, contososrv01\adfs.

sqlcmd -S <SQLServer\SQLInstance>

use master

go

sp_attach_db 'adfsconfiguration', 'c:\windows\sysmsi\ssee\mssql.2005\mssql\data\adfsconfiguration.mdf', 'c:\windows\sysmsi\ssee\mssql.2005\mssql\data\adfsconfiguration_log.ldf' go sp_attach_db 'adfsartifactstore', 'c:\windows\sysmsi\ssee\mssql.2005\mssql\data\adfsartifactstore.mdf', 'c:\windows\sysmsi\ssee\mssql.2005\mssql\data\adfsartifactstore_log.ldf'

go

alter database AdfsConfiguration set enable_broker with rollback immediate

go

5.       Change the configuration database connection string to point to the new SQL Server-based AD FS configuration database. Open a Windows PowerShell command-line, type the following command-line syntaxes in order, and then press ENTER after each one. In SQLServer\SQLInstance below, type in the appropriate SQL Server and SQL Server instance name where you are migrating the configuration data to. For example, contososrv01\adfs.

$temp= GEt-WmiObject -namespace root/ADFS -class SecurityTokenService

$temp.ConfigurationdatabaseConnectionstring=”data source=<SQLServer\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true

$temp.put()

6.       Open an elevated command-line prompt, type the following command-line syntax to start the AD FS 2.0 Windows Service, and then press ENTER:

Net start adfssrv

7.       Change the artifact connection string to point to the new SQL Server-based artifact data location. Open a WindowsPowerShell command-line, type the following command-line syntaxes in order, and then press ENTER after each one. In SQLServer\SQLInstance below, type in the appropriate SQL Server and SQL Server instance name where you are migrating the artifact data to. For example, contososrv01\adfs-artifact.

Add-pssnapin microsoft.adfs.powershell

Set-adfsproperties –artifactdbconnection “data source=<SQLServer\SQLInstance>; initial catalog=adfsartifactstore;integrated security=true”

8.       Stop and restart the AD FS 2.0 Windows Service to refresh the new settings. Open a regular command-line prompt, type the following command-line syntaxes to stop and start the AD FS 2.0 Windows Service, and then press ENTER after each one:

Net stop adfssrv

Net start adfssrv

Step 4: Performing steps on the secondary federation server

1.       Make sure the primary federation server has been added back to the load balancer before proceeding with this section.

2.       Make sure the secondary federation server has been temporarily removed from the load balancer before proceeding.

3.       On a secondary federation server in the farm, open an elevated command prompt, type the following command-line to stop the AD FS 2.0 Windows Service, and then press ENTER:

net stop adfssrv

4.       Change the configuration database connection string to point to the new SQL Server-based AD FS configuration database. Open a Windows PowerShell command-line, type the following command-line syntaxes in order, and then press ENTER after each one. In SQLServer\SQLInstance below, type in the appropriate SQL Server and SQL Server instance name where you are migrating the configuration data to. For example, contososrv01\adfs.

$temp= GEt-WmiObject -namespace root/ADFS -class SecurityTokenService

$temp.ConfigurationdatabaseConnectionstring=”data source=<SQLServer\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true

$temp.put()

5.       Open a regular command-line prompt, type the following command-line syntax to start the AD FS 2.0 Windows Service, and then press ENTER:

Net start adfssrv

6.       Change the artifact connection string to point to the new SQL Server-based artifact data location. Open a WindowsPowerShell command-line, type the following command-line syntaxes in order, and then press ENTER after each one. In SQLServer\SQLInstance below, type in the appropriate SQL Server and SQL Server instance name where you are migrating the artifact data to. For example, contososrv01\adfs-artifact.

Add-pssnapin microsoft.adfs.powershell

Set-adfsproperties artifactdbconnection data source=<SQLServer\SQLInstance>; initial catalog=adfsartifactstore;integrated security=true

7.       Stop and restart the AD FS 2.0 Windows Service to refresh the new settings. Open a regular command-line prompt, type the following command-line syntaxes to stop and start the AD FS 2.0 Windows Service, and then press ENTER after each one:

Net stop adfssrv

Net start adfssrv

8.       Verify that the service starts up successfully.

9.       Repeat these steps for every federation server in this Windows Internal Database-based farm.

Step 5: Enabling this computer on the load balancer

Enable the computer in the load balancer so that requests are sent to it. 

Working with Active Directory using PowerShell ADSI adapter

 

Working with Active Directory using PowerShell ADSI adapter (en-US)

Introduction

PowerShell is very useful for automating Active Directory. It allows to quickly and relatively easy automate mundane actions or perform same operations with many objects. PowerShell provides very broad set of methods to work with Active Directory. There is some of them:In this article provided examples of using ADSI adapter and .NET classes. This is not an easiest method, but sometimes you just need it. For example if you working in organization that uses old operating system for domain controllers (not 2008R2+), and you cannot install any additional software on controllers or servers, but need to work with Active Directory in your script.

Receiving an object representation of Active Directory object.

This method requires knowledge of object's LDAP path.
001
$Object = [adsi]'LDAP://CN=Notebook1,OU=Computers,DC=consoso,DC=com'

Searching for an object in Active Directory.

001 002 003 004
$Searcher = New-Object DirectoryServices.DirectorySearcher $Searcher.Filter = '(&(objectCategory=person)(anr=gusev))' $Searcher.SearchRoot = 'LDAP://OU=Laptops,OU=Computers,DC=consoso,DC=com' $Searcher.FindAll()
Filter property of the Searcher object uses standard LDAP query syntax  . You can also use FindOne() method to receive just first found object.

Setting "Password never expire" attribute on user object

This property unlike many other properties of AD object are contained in bitmask attribute UserAccountControl (not related in any way with User Account Control feature of Windows). To set it you need to retrieve current value of this attribute and use binary OR operation (-bor) to calculate new value. 
001 002 003 004
$User = [ADSI]"LDAP://cn=Gusev,ou=Users,ou=Lab,dc=contoso,dc=com" $UAC = $User.UserAccountControl[0] -bor 65536 $User.Put("userAccountControl",$UAC) $User.SetInfo()
  

Get direct AD group membership information

Members of the group are contained as Distinguished Names in Member array property of a group. To get objects representing the members one need to get contents of this property and create ADSI objects from them.
001 002
$Group = [ADSI]"LDAP://cn=Domain Admins,cn=Users,dc=Contoso,dc=Com" $Members = $Group.Member | ForEach-Object {[ADSI]"LDAP://$_"}
  Same way, groups in which AD object is directly included are contained in its MemberOf property. 
001 002
$User = [ADSI]"LDAP://cn=Administrator,cn=Users,dc=Contoso,dc=Com" $Groups = $User.MemberOf | ForEach-Object {[ADSI]"LDAP://$_"}
  

Get AD object class name

Primary class of AD object are contained in Class property, but there is also ObjectClass property that contains all classes to which object is belong.
PS C:\> $Object = [ADSI]"LDAP://cn=Administrator,cn=Users,dc=Contoso,dc=Com"
PS C:\> $Object.class
user
PS C:\> $Object.objectclass
top
person
organizationalPerson
user

 

Automate the installation of Active Directory tools with PowerShell

Automate the installation of Active Directory tools with PowerShell

Summary: The remote administration features of Windows Server 2008 allow the core tools to be run on any server. IT pro Rick Vanover shows how to automate the process.

When Windows Server 2008 was released, one of my observations was that Microsoft brought Server Manager back. Server Manager for Windows Server 2008 is much different than the tool of the same name in Windows NT Server, but you can still do a lot of administrative work in the console.

In many domain environments, I like having the Active Directory tools available on my favorite administrative servers. It is easy to add the Active Directory tools through the Remote Administration feature of Server Manager, but you can automate this configuration with PowerShell on Windows Server 2008.

You cannot add features directly through something like Group Policy, but you can use a script that will add the tools you use most on an administrative server. In my Windows administration practice, this includes the DNS console, the Active Directory Users And Computers snap-in, and the other core Active Directory tools. This PowerShell script will add these features:

Import-Module Servermanager
Get-WindowsFeature
Add-WindowsFeature RSAT-DNS-Server -restartAdd-WindowsFeature RSAT-ADDS-Tools -restart
Add-WindowsFeature RSAT-AD-AdminCenter -restart
Add-WindowsFeature RSAT-SNIS -restart

Note: These features require Windows to be restarted, so be advised that Windows may restart without prompting when passing the command to add these features in through PowerShell.

Iterating this script in PowerShell (saved as a .PS1 file) will proceed as shown in Figure A.

Figure A

 
Click the image to enlarge

This script can be coupled on to a server build script or passed as a one-time iteration through Group Policy if you see the need for a number of servers to use the Active Directory tools.

 

By installing these tools on a dedicated administrative server, you’ll be following a practice that many administrators use. Basically, one or more Windows Servers are dedicated for administrative tasks on a server class system, yet this system is not a server itself. Examples include being able to run this dedicated administration server centrally, such as a virtual machine, and leave it powered on at all times for things like scripts, process watchdogs, and management interfaces.

Furthermore, having all of the administrative tools centrally located on one or more dedicated administrative servers can help with firewall rules for certain administrative tasks if the need arises. This is due to a single IP address for the administrative tasks and tools in use.

Rick Vanover is an IT infrastructure manager for a financial services organization in Columbus, Ohio. He has years of IT experience and focuses on virtualization, Windows-based server administration and system hardware.