RSS

Active Directory Database Files

NTDS.DIT (DIT- Directory information Tree) – Active Directory’s database engine is the Extensible
Storage Engine(ESE)which is based on the jet database and can grow up to 70TB -This AD database and
stores all AD objects. Default location is %systemroot%\NTDS\ folder. Database name is NTDS.DIT.
NTDS. DIT consists of the following tables
Schema table the types of objects that can be created in the Active Directory, relationships between
them, and the attributes on each type of object. This table is fairly static and much smaller than the
data table.
Link table contains linked attributes, which contain values referring to other objects in the Active
Directory. Take the Member Of attribute on a user object. That attribute contains values that
reference groups to which the user belongs. This is also far smaller than the data table.
Data table users, groups, application-specific data, and any other data stored in the Active Directory.
The data table can be thought of as having rows where each row represents an instance of an object
such as a user, and columns where each column represents an attribute in the schema such as Given
Name.
From a different perspective, Active Directory has three types of data
· Schema information definitional details about objects and attributes that one CAN store in the AD.
Replicates to all domain controllers. Static in nature.
· Configuration information configuration data about forest and trees. Replicates to all domain
controllers. Static as your forest is.
· Domain information object information for a domain. Replicates to all domain controllers within a
domain. The object portion becomes part of Global Catalog. The attribute values (the actual bulk of
data) only replicates within the domain.
2. EDB.LOG – This is the transaction log file (10 Mb). When EDB.LOG is full, it is renamed to EDBnnnn.log
where nnnn is the increasing number starting from 1. [Edb corruption or Edb active directory
corruption is really serious. However you can get this repaired by using edb repair tool.]
Page 2 .
3. EDB.CHK – This is the checkpoint file used to track the data not yet written to database file. This
indicates the starting point from which data is to be recovered from the logfile, in case of failure.
4. RES1.LOG and RES2.LOG – This is reserved transaction log files of 20mb (10mb each) which provides
the transaction log files enough room to shutdown if the other spaces are being used.

 
Leave a comment

Posted by on August 25, 2014 in Active Directory

 

HOW TO VERIFY THE AD INSTALLATION IS PROPER

1. Verify SRV resource records. After AD is installed, the domain controller will register SRV records in DNS when it restarts. We can check the DNS, MMC or NSLOOKUP (is –t srv domain) command. If the SRV records are registered, the following folders will be there in the domain folder in forward lookup zone. (msdes, sites, tcp and udp)

2. Verifying SYSVOL. If SYSVOL folder is not properly created data stress in SYSVOL such are scripts, GPO, etc will not be replicated between domain controllers. Verify the folder structure in domain, staging, staging areas, sysvol. Then verify necessary shares are created (>net share or \\servername)

3. Verifying database log files in %system root%\ntds (ntds.dit, edb.*, res*.log).

 
Leave a comment

Posted by on August 25, 2014 in Active Directory

 

Quickest way to update your standalone host to ESXi 5.1

To update ESXi to 5.1 Update 1 run the following commands in an ESXi shell: 01    # open firewall for outgoing http requests:
02    esxcli network firewall ruleset set -e true -r httpClient
03    # install the ImageProfile from the Online Depot:
04    esxcli software profile install -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.1.0-20130402001-standard

05    # OR: update using this ImageProfile
06    # esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-5.1.0-20130402001-standard

07    # close the firewall port again (optional)
08    esxcli network firewall ruleset set -e false -r httpClient

This will only work if the host has a direct connection to the Internet, because it pulls the packages directly from the VMware Online depot.

If you just want to list all the image profiles (= patch bundles) that are available in the Online depot then you can do this with the command

If your host does not have a direct Internet connection then you need to download the Offline Bundle for ESXi 5.1 U1 on another machine, upload it to a datastore of the host using the vSphere client, and replace the https-link (after “-d”) in the above commands with the path to this zip-file.

Please note: Although the Offline bundle is named update-from-esxi5.1-5.1_update01.zip it can also safely be used to update an existing ESXi 5.0 installation.

It is important to notice the difference between “esxcli software profile install” and “esxcli software profile update“. The install command will remove all existing packages and install only what is included in the update bundle. In contrast the update command will keep any already installed package that is not included in the patch bundle (see also the help output for “esxcli software profile –help”). That means: If you have ever installed a custom driver or software package that is not included in the original VMware ISO then you want to use update to keep them.

If your hardware is an HP server then I recommend using the latest HP Customized installation bundle. Download the zip-file based on ESXi 5.1 U1 from this page and apply it in the same way as the vanilla VMware bundle:

1 esxcli software profile install -d /vmfs/volumes/datastore1/VMware-ESXi-5.1.0-Update1-1065491-HP-5.50.26-depot.zip -p HP-ESXi-5.1.0-standard

Just like the HP Customized installation ISO (that is available on the same page) this bundle includes the latest versions of the HP software packages needed for hardware monitoring and updated device drivers for all supported HP server models.

 
Leave a comment

Posted by on August 27, 2013 in ITIL / VMware

 

Exchange Server and its relationship to Active Directory

Within the last years we’ve got several new Windows Server versions, 2008 and 2008 R2 and now Windows Server 2012, and also some new Exchange Server versions, 2007, 2010 and now 2013. They now maybe have to coexist even with Windows server 2003/2008/2008R2 and Exchange Server 2003/2007/2010 or should be upgraded to new versions.

 

Exchange Server 2000 and Windows Server 2008 Operating System/Domain Controllers

- Exchange 2000 can’t be installed on Windows Server 2008.

- Exchange 2000 SP3 isn’t supported when working together with Windows Server 2008 or higher DCs.

- for upgrading to Windows Server 2008 or higher you have to check that no Exchange Mangled Attributes exist, this applies also for Windows Server 2008.

- if there is no other option then it should be possible to use the Windows Server 2008 DCs in a different site then the Exchange 2000 SP3.     !!!Keep in mind this isn’t supported configuration!!!

- if you really must use both in the same site then some additional configuration should help to hardcode (default is automatic discovery) the DSAccess on the Exchange 2000 to DCs with Windows Server 2003 or Windows 2000 Server OS. Open ESM and choose the “Directory Access” tab of the Exchange server properties. See also Directory server detection and DSAccess usage and Revert DSAccess to default for details.     !!!Keep in mind this isn’t supported configuration!!!

 

 

Exchange Server 2003 and Windows Server 2008/2008 R2 and 2012 Operating System/Domain Controllers

- Exchange 2003 can’t be installed on Windows Server 2008.

- Exchange 2003 can’t be installed on Windows Server 2012.

- if you use Exchange 2003 and have the need for connectivity to Windows Server 2008 or higher OS DCs, you have to use at least Exchange 2003 SP2.

- Windows Server 2008 and 2008 R2 RODCs (Read Only Domain Controllers) are not supported to work with Exchange Servers (doesn’t matter which version, as Exchange requires a writable Domain Controller).

- Windows Server 2012 DCs do NOT work together with Exchange 2003, doesn’t matter which SP is used.

 

Exchange Server 2007 and Windows Server 2000 Operating System/Domain Controllers

- Exchange 2007 can be installed on Windows Server 2003 SP2 or Windows Server 2003 R2 SP2 or higher OS, not on Windows 2000 Server.

- Exchange 2007 can work with Windows Server 2003 SP1/2 Domain Controllers or higher, not with Windows 2000 Server Domain Controllers.

- Exchange 2007 requires Windows Server 2000 Domain Native Functional Level / Windows 2000 Forest Functional Level, if Forest-to-forest delegation and the ability for a user to select the type of free/busy information that will be available to users in another forest is not needed.

 

Exchange Server 2007 and Windows Server 2003 Operating System/Domain Controller

- Exchange 2007 can be installed on Windows Server 2003 SP2 or Windows Server 2003 R2 SP2.

- Exchange 2007 can work with Windows Server 2003 SP1 and SP2 Domain Controllers.

- Exchange 2007 requires Windows Server 2003 Forest/Domain Functional Level.

 

Exchange Server 2007 and Windows Server 2008 / Windows Server 2008 R2 Operating System/Domain Controllers

- Exchange 2007 must be at least SP1 to be installed on Windows Server 2008 and also to work with Windows Server 2008 Domain Controllers.

- Exchange 2007 can be installed on Windows Server 2008 R2 if Exchange 2007 SP3 is used with some restrictions as listed here.

- you have to install “Update Rollup 9 for Microsoft Exchange Server 2007 Service Pack 1” or later, to be able to work with Windows Server 2008 R2 Domain Controllers and also to use the Forest/Domain Functional Levels Windows Server 2008 R2 or use Exchange Server 2007 Service Pack 2.

- Windows Server 2008/2008R2 and 2012 RODCs (Read Only Domain Controllers) are not supported to work with Exchange Servers (doesn’t matter which version, as Exchange requires a writable Domain Controller).

 

Exchange Server 2010 and Windows Server 2003/2008 Operating System/Domain Controllers

- Exchange 2010 can be installed only on the 64bit edition from Windows Server 2008 SP2 or 2008 R2, FIPS compliant settings are NOT supported.

- Exchange 2010 will work together with 32/64 bit version of Windows Server 2003 Standard Edition/Enterprise Edition SP1 or later Schema Masters/Domain Controllers/Global Catalog Servers.

- Exchange 2010 requires Windows Server 2003 Forest/Domain Functional Level or higher.

- Exchange 2010 can coexist with Exchange 2003 and higher Exchange versions, also in mixed organizations.

- Exchange 2010 SP3 can be installed on Windows Server 2012.

- Windows Server 2008/2008R2 and 2012 RODCs (Read Only Domain Controllers) are not supported to work with Exchange Servers (doesn’t matter which version, as Exchange requires a writable Domain Controller).

 

Exchange Server 2013 and Windows Server 2008 R2 SP1/Windows Server 2012 Operating System/Domain Controllers

- Exchange 2013 can be installed on Windows Server 2008 R2 SP1(ONLY DataCenter Edition support RTM or later) or Windows Server 2012

- Exchange 2013 will work together with 32/64 bit version of Windows Server 2003 Standard Edition/Enterprise Edition SP2 or later Schema Masters/Domain Controllers/Global Catalog Servers.

- Exchange 2013 requires Windows Server 2003 Forest/Domain Functional Level or higher.

- Exchange 2013 (CU1) can coexist with Exchange 2007 SP3 and Update Rollup 10(on all Exchange servers in the organization, including Edge Transport servers) and Exchange 2010 SP3(on all Exchange servers in the organization, including Edge Transport servers), also in mixed organizations.

- Windows Server 2008/2008R2 and 2012 RODCs (Read Only Domain Controllers) are not supported to work with Exchange Servers (doesn’t matter which version, as Exchange requires a writable Domain Controller).

Upgrading of Exchange inside Domains

- in place upgrades to Exchange 2007 or higher aren’t possible, the needed process is Exchange Organization transitioning.

- the Planning Roadmap for Upgrade and Coexistence with Exchange 2010 from Exchange 2003 and Exchange 2007 contains all needed information.

- Exchange 2003 – Planning Roadmap for Upgrade and Coexistence.

- Exchange 2007 – Planning Roadmap for Upgrade and Coexistence.

- Active Directory is one requirement to install Exchange 2007, Exchange 2010 and Exchange 2013

 

Migration from Exchange to another Forest/Domain

- this can be achieved with Cross Forest Migration when MIIS is used, Single Forest to Cross Forest and Cross Forest to Cross Forest.

- it is possible to Move Mailboxes Across Forests in Exchange 2007 and Cross Forest Mailbox Move also works in Exchange 2010.

- another option is to export mailboxes from the existing Exchange Servers to .pst files and import them into the new Exchange organization with Powershell command lets.

- Exchange 5.5, 2000 and 2003 Mailboxes can be exported with EXMERGE from Exchange 2003 Servers or computers installed with Exchange 2003 Administrative tools installed.

- Exchange 2007 Export-Mailbox and Import-Mailbox, requires 32bit Exchange management tools and Outlook 2003 SP2 or later.

- Exchange 2010 Export-Mailbox and Import-Mailbox , requires Exchange Server 2010 and 64bit version of Outlook 2010.

- Exchange 2013 New-MailboxExportRequest and New-MailboxImportRequest, requires additional permissions so check the article for correct settings.

 
Leave a comment

Posted by on August 26, 2013 in Exchange Server

 

Microsoft-Windows-GroupPolicy event 1502 not being logged after successful application of GPOs

The group in question is actually created by an event-triggered task, visible in Task Scheduler here:
Microsoft > Windows > RemoteAssistance > RemoteAssistanceTask

Viewing the Triggers tab for this task, it is fired by the following:
Log: System, Source: Microsoft-Windows-GroupPolicy, Event ID: 1502

Manually launching the task made the group appear immediately, so we knew at this point that the problem lay with the event trigger.

Checking the System event log, there were 0 events matching the given source & ID, yet running GPRESULT /Z made it clear that the policies were applying successfully.

GPUDPATE /FORCE refreshed the policies correctly, but also failed to get the 1502 event logged.

So the first thing we did was to enable gpsvc debug logging, by setting the following registry value:
Path: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Name: GpSvcDebugLevel
Type: REG_DWORD
Data: 0x30002

The debug logging is written to the following location:
%windir%\debug\usermode\gpsvc.log

After refreshing the policies we saw the following being recorded in gpsvc.log:
GPSVC(xxx.yyy) hh:mm:ss:sss Could not publish event id=1502 as it is disabled

This is logged because the Group Policy service makes a call to EtwEventEnabled and receives FALSE in response.

we stepped through the code for EtwEventEnabled, and there are 3 checks made, and if any of them fail then FALSE is returned.

The first check is that the ETW event is not marked as “disabled” through a dedicated flag (this was okay).

The second check is that the level of the event to log is not outside of the threshold for the provider (this was also okay).

The third check is the Keyword matches the bitmask for event types to log – it turns out the REGHANDLE passed to this function referred to the ETW provider with bad types for MatchAllKeyword and MatchAnyKeyword values.

From the EtwEnableCallback routine page on MSDN:

MatchAnyKeyword [in]

The bitmask of keywords that the provider uses to determine the category of events that it writes.

This value is passed in the MatchAnyKeyword parameter of the EnableTraceEx function or the EnableFlag parameter of the EnableTrace function. MatchAnyKeyword is a 64-bit value and is basically an extended version of the 32-bit EnableFlag.

MatchAllKeyword [in]

This bitmask additionally restricts the category of events that the provider writes.

This value is passed in the MatchAllKeywords parameter of the EnableTraceEx function.

When we looked at these filter values for the EventLog-System provider on the broken clients, they were present and at a glance contained good data, but they were created as REG_SZ (string) values rather than the expected REG_QWORD (64-bit number, as the clients were x64).

The path to the key holding the values is:
HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\EventLog-System\{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}

After replacing the REG_SZ values with the correct type, the clients started recording event ID 1502 when refreshing group policy.

-Thanks to Paul

 
Leave a comment

Posted by on August 26, 2013 in Active Directory

 

Cloning Domain Controllers from the GUI

Cloning a Domain Controller is done in seven steps:
1. Allow the source Domain Controller to be cloned
In the previous chapter I explained how Active Directory in Windows Server 2012 is now virtualization-safe; Virtualization Admins no longer need to know which virtual machines to be careful with and Active Directory Admins no longer have to fear the work done by the Virtualization Admins.
For Active Directory Admins to keep control of their virtual Domain Controllers, they are the ones to authorize their servers for Domain Controller Cloning. When a Domain Controller is unauthorized, a Virtualization Admin cannot clone a virtual Domain Controller. When reusing a virtual hard disk of an unauthorized Domain Controller, it will boot into the Domain Services Restore Mode.
To authorize a Domain Controller for Domain Controller Cloning, it’s computer object needs to be made a member of the Cloneable Domain Controllers global security group, located in the Users container.

Alternatively you can grant the DS-Clone-Domain-Controller extended right, as, under the hood, this is the right the Cloneable Domain Controllers group grants.

2. Resolve Service Principal Name issues
One of the limitations of Domain Controller Cloning is the ability to clone Service Principal Names (SPN). Therefore, you should manually check for SPNs on the Domain Controller before cloning a Domain Controller. The following PowerShell one-liner, when run on the source Domain Controller, shows you the Service Principal Names in use:
Get-ADServiceAccount –filter:”*”

3. Resolve problems with non-cloneable applications, agents and services
Applications, agents and services in use on Domain Controllers might pose a challenge when you clone a Domain Controller. Microsoft has done an incredible amount of work to make sure their services are cloneable.
This work can be seen when examining C:\Windows\System32\DefaultDCCloneAllowList.xml. However, with new applications, agents and services being released by both Microsoft and other vendors, we are bound to bump into software that has not been tested, yet. To get a list of installed software that is not on the list of tested software (DefaultDCCloneAllowList.xml), perform the following PowerShell one-liner:
Get-ADDCCloningExcludedApplicationList
This command might return a set of applications and services that are not tested. Now, when the Domain Controller Cloning process runs into an application, agent of service that is not on the Default Domain Controller Clone Allow List (DefaultDCCloneAllowList.xml) it will feel it is not allowed to perform the clone. When the command doesn’t detect any untested applications, agents or services, you and the Domain Controller are good to go to the next step. When the command returns programs or services, you need to resolve the issues. You can do this in two ways:
1. Uninstall the program or service (temporarily).
2. (Work with the software vendor to) Test the application, agent and/or service for cloning.

4. Write the DcCloneConfig file
In this step we specify the configuration of the target Domain Controller; the Domain Controller that will be the result of Domain Controller cloning. For this purpose we write a DCCloneConfig.xml file.
As the basis for our file, we use C:\Windows\System32\SampleDCCloneConfig.xml

it has predefined fields we can use to specify configuration information for the new Domain Controller. When you work with DHCP Reservations for your Domain Controllers, are fine with Microsoft-generated Domain Controller names and want the target Domain Controllers to show up in the same Active Directory site as the source Domain Controller, you can use this file as is and save it as DCCloneConfig.xml in one of the following locations:
 the same folder as the Active Directory database (ntds.dit) on the source Domain Controller.
 In the root of (virtual) removable media, such as virtual floppy drives (*.vfd files) or virtual CD- and DVD-drives (*.iso-files).

5. Copy the virtual hard disk of the source Domain Controller and base the target Domain Controller on it
Now, the source Domain Controller is fully checked, prepped and authorized. A Virtualization admin can now copy its virtual hard disk VHD and create a new Virtual Machine, with that virtual hard disk.

6. Start the target Domain Controller
Now it’s time to feed the virtual machine its DCCloneConfig.xml file when using removable media and start it up.
When successful, the target Domain Controller will boot up and display its progress in Domain Controller cloning.

7. Restore any (temporarily) removed functionality
After the Domain Controller is done cloning, log on and restore any (temporarily) removed applications, agents, services and Service Accounts.

 
Leave a comment

Posted by on July 24, 2013 in Active Directory

 

Creating & Assigning a Fine-grained Password Policy in the GUI

If you want to, you can create a Fine-grained Password Policy without a link within the Active Directory Administrative Center. For this purpose, open the Active Directory Administrative Console, using an account with sufficient permissions to create Fine-grained Password Policies.
In the left navigation pane, head to the System container under the domain root and from there drill deeper until you reach the Password Settings Container. This is where Fine-grained Password Policies live in Active Directory:

Now, you can use the New and then Password Settings commands from the task pane on the right, or simply right-click within the middle pane and make the same selections from the context menu to create a Fine-grained Password Policy.

In the Create Password Settings screen, you can give the Fine-grained Password Policy a meaningful Name and a Precedence. (both fields are mandatory.)

Assigning a Password Policy to a user in the GUI
To assign a Fine-grained Password Policy directly to a user, open the properties of a user account in the Active Directory Administrative Center. In the left pane, select Password Settings. Use the Assign… button to select a Fine-grained Password Policy

Use the Check Names functionality to make picking easier and click OK when done.

 
Leave a comment

Posted by on July 22, 2013 in Active Directory

 
 
Follow

Get every new post delivered to your Inbox.

Join 1,182 other followers