Do Until objRecordSet.EOFWscript.Echo objRecordSet.Fields("Name").ValueWscript.Echo objRecordSet.Fields("sAMAccountName").ValueWscript.Echo objRecordSet.Fields("legacyExchangeDN").ValueobjRecordSet.MoveNextLoop

This script lets you manually bind to the domain/application partition.

Do Until objRecordSet.EOFWscript.Echo objRecordSet.Fields("Name").ValueWscript.Echo objRecordSet.Fields("sAMAccountName").ValueWscript.Echo objRecordSet.Fields("legacyExchangeDN").ValueobjRecordSet.MoveNextLoop

Well if I connect to my application partition created during the LDS installation wizard and go to my Administrators, I can see nested inside is another Administrators group residing inside the Configuration Partition.

I can now connect to this using ADSIEdit.

Under the administrators group in the configuration partition I can find the account used when I installed the LDS Instance as per Microsoft documentation on TechNet.

In this post I will describe Aging with ADAMSync. If you configure ADAMSync to replicate your Active Directory information to an LDS Instance, without aging deleted data from Active Directory will never be removed from LDS. For example if you delete a user object from your Active Directory database, this object will not be deleted from the LDS Instance when you run the next sync.

- If it's set to "0", the Aging will be skipped, AdamSync will return the following informaiton:a. Aging is skipped. b. The times since the last sync.

- If it's larger than "0", system will compare its value with the number of times since the last sync:

a. If its value is larger than the number of times since the last sync, Aging will be skipped, and the number of the times since the last sync will be increased by 1.b. if its value is not larger than the number of times since the last sync, Aging procedure will be called and the number of times since the last sync will be reset.

Examples:

- If the value is set to 0, aging will be not used.- If the value is set to 1, the aging will be called each time during the sync. - if it's set to 2, the aging will be called every two sync.

num-objects

num-objects is the number of objects that need to be aged per run. If you make this 0, it will always age all objects against Active Directory. If you make this 50, it will only age 50. When you perform the next sync, it will age the next 50. Don't worry all objects will eventually be aged... depends on how often you schedule task adamsync.exe to run!

Why was Aging developed?

Please read this fantastic article by Eric Fleischman which explains why Aging was developed by Microsoft in ADAMSync.

Thankyou to James Li from the Directory Services Support Team at Microsoft for looking at the source code of ADAMSync.exe and explaining how the code works! This information was published with written permission from Microsoft via email.

When setting up Active Directory delegation, you want administrators to be able to maintain Group Policy without being a Domain Admin. If you read TechNet, Microsoft tells you to use Group Policy Creator Owners, please see:

Lets test it. We have a user named Jess. Jess is only a member of the domain users group. We add Jess to "Group Policy Creator Owners". Jess creates a group policy object called "Jess's Policy". Great, it worked. If we look at the permissions of "Jess's Policy" in group policy management console (GPMC), we see that she has permissions to the group policy object.

Jess does not have permissions to modify or edit any other group policy objects.

The problem with Group Policy Creator Owners

Lets say you have 10 administrators that need to make group policy changes. You add the 10 administrators to Group Policy Creator Owners. One administrator creates a group policy object. The others cannot read or modify the group policy object as only the administrator that created the group policy object owns it. The administrator that created the group policy object must remember to grant the other administrators access to the group policy object. This process needs to re-occur every time an administrator creates a new group policy object.

I don't know why Microsoft recommends to use this approach for group policy delegation as it is not feasible.

Schema permissions are written by using the Security Descriptor Definition Language (SDDL).

Note: These SID's will be different in your environment as the beginning of a SID is unique to the given domain.

The beginning of each ACL states what permissions are set over the group or username entry. The second part shows the SID of the group/user account.

I have created a group called AD-GPO-M that I want to add to the template permissions to ensure they get applied to all new group policy objects. We added the following to the end of my SDDL on the defaultSecurityDescriptor attribute. This is the SID that is append to the AD-GPO-M security group.

Now when I created a new group policy object (GPO) called "Test PCI Member Server" the following permissions were granted by default:

This has now given your non-domain admins who are a member of this group permissions to administer this new group policy object.

For any existing group policy objects they will not currently have access, however you can reset permissions to default which will pull the permissions down from the defaultSecurityDescriptor attribute.

Whenever you make a change to permissions on a group policy object in group policy management console (GPMC) it will modify permissions on both the Active Directory object and SYSVOL.

In Active Directory the group policy objects are stored under your domain partition --> System --> Policies.

Caution for Multi-Domain Forest

In a multi-domain forest, your administrator account may reside in a Child Domain. You may be nested in the Schema Admins group in the forest root domain. When you use ADSIEdit to modify the CN=Group-Policy-Contrainer on the schema partition you may receive the following error:

Operation failed. Error code: 0x202b
A referral was returned from the server.

0000202B: RefErr: DSID-030A0B09, data 0, 1 access points
ref 1:

I found you need to connect to the schema master in your forest root domain to make this change in ADSIEdit. This resolved the problem.

Wednesday, August 3, 2011

In previous versions of Exchange 2003-2007 there was a feature called SIS (Single Instance Storage). This meant if an email was sent to multiple mailboxes in a distribution group, it would only get stored in a mailbox database once. When designing database layout it was recommended you group users of a similar operational role under the same mailbox database. This ensures when emails are sent to distribution groups, the email is only stored in the database once.

In Exchange 2010, SIS has now been removed to help improve performance allowing low cost disk to be utilized. This was one of the key factors in reducing disk I/O on the Exchange database.

The decision behind this was around using low cost TIER2 SATA disk, who cares if emails are stored multiple times inside a database?

Have a read of Ross Smith IV's article explaining this in more detail: