Sunday, April 24, 2011

MSExchangeIS EventID 1121 and 5000

I had an issue today where the Information Store service would not start on any Exchange 2010 server. When you went to start the Information Store service the following error appears:

Windows could not start the Microsoft Exchange Information Store on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code -2147221233.

The following errors were appearing in my application log:

Error 0x8004010f connecting to Active Directory.

Unable to initialize the Microsoft Exchange Information Store service. - Error 0x8004010f.

If you experienced these errors you may not have the same problem! There is more then one cause for these error codes..

In my case these errors were occurring because there was no default recipient policy or email address policy. Recipient Policies were the name in Exchange 2000/2003. Email Address Policies are the new name under Exchange 2007/2010. They are the same class object in Active Directory and stored under the same location within the schema.

The default email address policy displays in Exchange System Manager or Exchange Management Console with a priority of Lowest. Each additional policy gets a priority of 1 upwards... 2, 3, 4, 5 etc. When Exchange processes the recipient policy it starts from the highest number an works its way down. Recipient policies have LDAP filters, if a match is made with the filter, the policy is applied. If a policy is applied to a user, no additional policies are processed.

When I went to Exchange Management Console I had a single "Default Policy" under my Email Address Policies, however it had a priority of 1, not "Lowest". No policy had a priority of "Lowest". No email address policy was the default! This was causing the information store not to mount.

I used ADSIEdit to set a default policy by connecting to the configuration partition. The policies located under:

CN=Recipient Policies\CN=\CN=Microsoft Exchange\CN=Services\CN=Configuration\DC=domain\DC=local

To set a policy as the default email address policy, configure the priority to be 2147483647. This value is hard coded into Exchange to be the default email address policy. This value needs to be associated with the msExchPolicyOrder attribute.

There is one more attribute that is also hard coded into Exchange, which enables a policy to become the default email address policy. That attribute is purportedSearch. This attribute must be set to (mailNickname=*).

Once these attributes were set correctly Exchange recognized an email address policy. The information store was now able to start on all servers after AD replication completed.

There is also a TechNet article that provides some information into this error:

Tuesday, April 19, 2011

Exception: The Active Directory user wasn't found

I was doing work for a client who recently just had their single Exchange 2003 server upgraded to an Exchange 2010 clustered environment.

When trying to access a public folder database using the new ExFolders tool (the replacement for PFDavAdmin) the following error was experianced:

An error occurred while trying to establish a connection to the Exchange server.

Exception: The Active Directory user wasn't found.

This was resolved by deleting the CN=Servers container from the old administrative group using ADSIEdit. By default this administrative group is called First Administrative Group.

Thursday, April 14, 2011

Why is my server blue screening?

Why is my server blue screening?

Lets analyze that crash dump...

How to analyze a dump file

VSApiNt.sys = Trend Micro

Why am I not surprised.

Seriously over that product... the amount of Trend Micro related problems I have seen over the past few years I can honestly say if it was a choice between Trend Micro on your servers and no antivirus, I would take no antivirus.

Wednesday, April 13, 2011

How to Meet Payment Card Industry Data Security Standard Compliance

Payment Card Industry Data Security Standard (PCI DSS) is a complex set of rules and requirements that applies to every person, business or organisation that handles credit card data. This includes any person, business or organisation that receives, stores, processes or transmits credit card details.

The PCI DSS is a product of the Payment Card Industry Security Standards Council, an organisation founded by participating payment brands Visa International, Master Card, American Express, Diners Club and JCB.

The purpose of the Payment Card Industry Security Standards Council is to establish a uniform world wide standard to aggressively addresses vulnerability and risk associated with the handling of credit card data across all industries.

In this post I will be giving a few tips around how to get your Microsoft Environment to meet PCI DSS compliance.

What is PCI DSS?

First of all you must understand the PCI DSS compliance requirements. Head over to the e-Path website to get an understanding of the rules and requirements around PCI DSS compliance. There is links to PCI Security Standards Council - Supporting documentation which lists everything involved around bring your organisation align with PCI DSS compliance.

What do I need to become PCI DSS compliant?

Once you understand the requirements next you need to understand what technology is available to meet these requirements. Microsoft has published an article called "Payment Card Industry Data Security Standard Compliance Planning Guide" which documents all the various Microsoft Technologies available in meeting the PCI requirements. This document is aimed primarily at CIO's and IT Managers however a more detailed target audience is listed inside the document. Download this document from the following location:

Note: The are many third party (non Microsoft products) that can help you meet PCI DSS compliance, look elsewhere for these.

Microsoft Security Guide

Next you should look at the Microsoft Security Guide for meeting PCI DSS compliance. This provides an overview for the Security Compliance Management Toolkit which is a bunch of administrative tools for locking down a Microsoft Windows network.

The Microsoft Solution Accelerators - Security and Compliance (SA-SC) team developed the security guides included in this suite to provide you with recommendations for hundreds of Group Policy security settings designed to assist customers in making the environments of their organizations more secure.

These SA SC team created two policy sets for different environments:
- Enterprise Client (EC)
- Specialized Security - Limited Functionality (SSLF)

Both meet PCI DSS requirements!

Enterprise Client (EC)

The Enterprise Client (EC) environment referred to in this guidance consists of a domain using AD DS in which computers running Windows Server 2008 with Active Directory manage client computers that can run either Windows Vista or Windows XP, and member servers running Windows Server 2008 or Windows Server 2003 R2.

The domain controllers, member servers, and client computers are managed in this environment through Group Policy, which is applied to sites, domains, and OUs. Group Policy provides a centralized infrastructure within AD DS that enables directory-based change and configuration management of user and computer settings, including security and user data. The Group Policy this guide prescribes does not support client computers running Windows® 2000.

Specialized Security - Limited Functionality (SSLF)

The Specialized Security – Limited Functionality (SSLF) baseline in this guide addresses the demand to help create highly secure environments for computers running Windows Server® 2008. Concern for security is so great in these environments that a significant loss of functionality and manageability is acceptable. The Enterprise Client (EC) security baseline helps provide enhanced security that allows sufficient functionality of the operating system and applications for the majority of organizations.

Caution: The SSLF security settings are not intended for the majority of enterprise organizations. To successfully implement the SSLF settings, organizations must thoroughly test the settings in their environment to ensure that the prescribed security configurations do not limit required functionality.

If you decide to test and deploy the SSLF configuration settings to servers in your environment, the IT resources in your organization may experience an increase in help desk calls related to the limited functionality that the settings impose. Although the configuration for this environment provides a higher level of security for data and the network, it also prevents some services from running that your organization may require. Examples of this include Remote Desktop, which allows users to connect interactively to desktops and applications on remote computers.

For a copy of the Windows Server 2008 Security Guide visit the following location:

Note: This documentation refers to using the "Security Compliance Management Toolkit". This toolkit has now been replaced by "Microsoft Security Compliance Manager 1.0".


The Security Compliance Management Toolkit contains a tool called GPOAccelerator which automatically creates all the GPOs that you need to deploy the recommended security settings for your environment allowing you to meet PCI DSS requirements.

By using GPO Accelerator it saves you time preventing the need for manually editing policy settings and applying templates. It can create the recommended GPO lockdown policies for each type of windows server:

All of the GPOs that the GPOAccelerator creates are fully populated with the settings.

The GPOAccelerator will also create lockdown policies for your workstations.

Please see the following link to download the GPOAccelerator whitepaper:

Note: GPOAccelerator was a tool included in the Security Compliance Management Toolkit. Security Compliance Management Toolkit is now retired and has been replaced with Microsoft Security Compliance Manager 1.0. Microsoft Security Compliance Manager 1.0 now includes a tool called Local Policy Tool (LPT) which takes over the functionality of GPOAccelerator. Please use LPT to create your security policies to meet PCI DSS requirements.

Auditing Requirements for PCI DSS

I read an excellent article on the auditing requirements for PCI DSS. To understand the Auditing Requirements please read:

Sunday, April 10, 2011

Exchange 2003 Mailbox Manager Policies

Mailbox management recipient policies are a set of configurable rules that run on a schedule and that evaluate the mailboxes on the local server. The policy uses rules to filter all the recipient objects and to selectively apply mailbox management settings to messages in folders that go past the limit of the predefined rules.

The mailbox management process detects folders in a mailbox that contain messages larger than a certain size. If a message remains in a folder after a predefined time has passed (by default, 30 days), a number of predefined actions can be taken, including the following:
- Generate a report only and send the report to the mailbox owner.
- Move the message to the Deleted Items folder.
- Move the message to System Cleanup folders.
- Delete the message immediately.

Note Use caution when you use the Delete the message immediately option, because users may have to recover their messages.

If you use recipient policies, it is easy to apply or revise the rules. You do not have to reconfigure settings individually on each object. You can also change recipient policy priority levels to change the way that multiple policies are adjusted.

Note There is no default recipient policy for mailbox management (unlike the e-mail recipient policies). However, you can add the required property page to the default recipient policy if you want to create a mailbox management policy that applies to all recipients.

How do you configure Mailbox Manager Policies on the recipient policies?

Well by default these options are hidden. Right click on a recipient policy and click "Change property pages".

Click Mailbox Manager Settings.

Now the Mailbox Manager Settings will be visible under the Recipient Policy Properties.

Policies are applied according to the schedule that you set up on each server. This prevents mailbox management from running on all servers in the organization at the same time. However, you can force a manual update if you want a recipient policy to apply immediately.

Note Like e-mail recipient policies, the highest priority recipient policy that applies to an Exchange Server object is the effective policy. Lower priority policies are no longer evaluated after a match has been made.

When you use mailbox management recipient policies, you can configure a filter rule that specifies the subset of messaging-enabled objects that the recipient policy applies to. The recipient policy is then applied to objects that match the filter conditions.

This is useful when you have a subset of users who have different storage requirements. For example, there may be a technical author in your organization who regularly sends out very large attachments that must be stored. You can use a less restrictive mailbox management policy for this user.

Note You can configure mailbox storage limits to obtain a similar result. However, make sure that you note the following differences between mailbox storage limits and mailbox management recipient policies:
- Mailbox storage limits limit the total size of the mailbox.
- Mailbox management recipient policies limit messages over a certain size.

Mailbox Management must be configured to automatically run for the Mailbox Manager policies to apply. This needs to be configured on the server level in System Manager:

You can also choose to run this manually by right clicking on the Exchange 2003 server in system manager going to All Tasks.

Some parts of this document were taken from KB319188. Please refer to this article for some additional information:

Whats the difference between ACL, ACE, DACL and SACL?

A security descriptor contains two access control lists (ACLs) used to assign and track security information for each object: the discretionary access control list (DACL) and the system access control list (SACL).

Discretionary access control lists (DACLs). DACLs identify the users and groups that are assigned or denied access permissions on an object. If a DACL does not explicitly identify a user, or any groups that a user is a member of, the user will be denied access to that object. By default, a DACL is controlled by the owner of an object or the person who created the object, and it contains access control entries (ACEs) that determine user access to the object.

System access control lists (SACLs). SACLs identify the users and groups that you want to audit when they successfully access or fail to access an object. Auditing is used to monitor events related to system or network security, to identify security breaches, and to determine the extent and location of any damage. By default, a SACL is controlled by the owner of an object or the person who created the object. A SACL contains access control entries (ACEs) that determine whether to record a successful or failed attempt by a user to access a object using a given permission, for example, Full Control and Read.

Friday, April 8, 2011

UserProxy Class and ADAM / LDS

In this blog post I will be talking about the UserProxy Class which is used to create UserProxy Objects in ADAM / LDS Partitions.

ADAM = 2003 and prior name
LDS = Windows Server 2008 name
ADAM = Active Directory Application Mode
LDS = Lightweight Directory Service

They are both the same thing!

For LDS to forward authentication requests onto Active Directory we need to use UserProxy objects. These are objects get created in an application directory partition within an LDS instance.

In LDAP sense connecting to a database/object is often referred to as binding.

ProxyObjects allow you to use bind redirection, ADAM can accept and process bind requests to an ADAM proxy object that contains as one of its attributes the security ID (SID) from an Active Directory security principal. With ADAM, you can use bind redirection to provide Active Directory users with access to both ADAM data and Active Directory data, using Active Directory domain credentials as a single sign-on (SSO). In addition, you can use ADAM proxy objects to store user data that is specific to a particular application in ADAM, while using Active Directory to store more widely used directory data.

Bind redirection enables a user to bind to ADAM by means of a simple bind while still using Active Directory credentials. Other types of binding with Active Directory credentials work without requiring a proxy, but a simple bind does not. Proxy binding works only for a simple bind.

The ADAM .ldf files, which you can import into the ADAM schema during ADAM setup, contain an object definition for the object userProxy, which can be used for bind redirection. This object contains attributes that include a distinguished name and a SID. By creating a userProxy object in ADAM—specifying a distinguished name to be used for binding—and by using a valid SID from an Active Directory user account, you can bind to ADAM using bind redirection.

There are 4 "types" of users class objects provided by Microsoft:
- InetOrgPerson (the universal standard for LDAP users)
- User (the Microsoft standard lol)
- Organizational-Person (I have never used this)
- UserProxy

There are three default LDF files which you can use to create the userProxy class object in the ADAM/LDS Instance schema. These all exist in the default ADAM folder in your ADAM installation. These LDF files are the ones I was referring to above.

MS-UserProxy.ldf - contains the definitions for the userProxy class only.
MS-InetOrgPerson.ldf - Contains the definitions for all user classes including InetOrgPerson, User, Organizational-Person and userProxy.
MS-User.ldf - Contains definitions for all user classes excluding the InetOrgPerson class.

When would you want to use a userProxy object. Well you may have an external company that has an application that needs to authenticate with objects (such as users) in your Active Directory domain. Creating userProxy objects allows you to have ADAM authenticate logon credentials using AD usernames and passwords from the a domain controller without the application connecting to a domain controller. userProxy objects are very similar to AD and ADAM User objects except they do not store passwords and has an objectSID attribute that contains the SID from the linked AD User object. The SID of the userProxy object matching the User object in Active Directory is key - this is how the proxy works!

You can create userProxy objects using ADSIEdit console or using command line tools however this can be tedious. You can do this automatically for all users in an AD domain partition if you setup something like ADAMSync to synchronize. If you are preparing to use ADAMSync you need to perform the schema expantions on the ADAM partition for ADAMSync to work. You also must import the same Schema extension as your AD FFL to ensure all attributes you wish to sync exist in the ADAM instance schema. There are templates for this in the ADAM folder such as MS-AdamSchemaW2K3.LDF which is the 2003 FFL (Forest Functional Level) schema. When performing syncronization you create an LDAP configuration file which states exactly which attributes will be synced.

By default a SSL certificate required when using Userproxy objects however you can modify this by editing the configuration partition:

CN=Directory Service,CN=Windows NT, CN=Services, CN=Configuration

Change the Attribute RequiresSecureProxyBind from 1 to 0.

The reason it requires SSL by default is to encrypt the user and password information when being transmitted. ADAM does not support kerberos v5, so you must use Secure LDAP (LDAP with SSL Certificate) to protect information. You can use self signed certificates using something like selfssl.exe from the IIS Resource Kit or an internal PKI... or even public if you wish to spend money.

To be able to create UserProxy objects we must extend the ADAM schema to ensure the UserProxy class exists. Objects are created from Class objects.

One more thing, if your going to use userProxy, make sure the ADAM server is a member of the domain that trusts the AD users matching the SIDs in the userProxy objects. If the ADAM server is not a member of the domain they won't work as bind proxies as bind proxies rely on the underlying Windows security infrastructure to be able to forward the authentication to Windows/AD.

What happens if there is more then one domain? The ADAM server can only be a member of one domain! Will userProxy be able to forward authentication requests on to the appropriate domain over the trust links?

The answer is yes, user proxy objects can forward authentication requests over forest trusts, parent child trusts and tree root trusts.

I hope you have learnt something today, I have! Tip:

Buy Brian Desmonds [MVP - Directory Services] book, Active Directory forth edition. Its an awesome read:

Sunday, April 3, 2011

Exchange 2010 RPC Encryption

Exchange 2010 RTM had RPC Encryption enabled on the Client Access Servers by default. This meant outlook 2003 clients needed to be configured to support MAPI Encryption by configuring the outlook profile.

In Exchange 2010 SP1 RPC Encryption is now disabled by default.

However if you upgrade an Exchange 2010 RTM server to Exchange 2010 SP1 RPC Encryption will remain enabled.

Only fresh installs of Exchange 2010 SP1 will have RPC Encryption disabled.