Thursday, June 24, 2010

Using LDP.exe to Search Active Directory

LDP.exe is a useful tool for querying information out of Active Directory, in particular performing searches.

To perform a search using LDP.exe perform the following actions:

1. Open LDP.exe, go to connection and click Connect. Type in the address of one of your domain controllers.

2. Click connect and go to bindings. Enter a user name, password and domain name to which you want to connect with.

3. Click Browse and then click Search. In Base Dn enter the location in which you want to start searching from. Under filter type in a filter, I said any objects in active directory containing the msExchHomeServerName attribute, and if the attribute contains anything return the results. Also click subtree, this means it will search all recursive tree's in the LDAP structure.



4. Click Options. Under Attributes specify which attributes you want to return for each object found meeting your search query.



Perform the search, very easy!

Microsoft KB224543 has lots more information about this:

http://support.microsoft.com/kb/224543

Sunday, June 20, 2010

Unexpected error refreshing Server Manager

I had a Windows Server 2008 x64 server where I could not go to server manager roles or features. I would get the following error message:

Unexpected error refreshing Server Manager: No signature was present in the subject. (Exception from HRRESULT: 0x800B0100)

For more information, see the event log: Diagnostics, Event Viewer, Applications and Services Logs, Microsoft, Windows, System Manager, Operational.



I checked the server manager logs (C:\Windows\logs\ServerManager.log) the following error existed.

10280: 2010-02-01 12:17:39.000 [Extensibility] Error (Id=0) Could not detect the sku extensibility path: -1073418222
10280: 2010-02-01 12:17:41.538 [LoadExtensionAssemblies] No extension assemblies registered.
10280: 2010-02-01 12:17:41.843 [OobOptionalComponentInfo] Loading OCs from registry.
10280: 2010-02-01 12:17:44.269 [CBS] LastModified CBS Time (UTC): 01/17/2010 00:21:06
10280: 2010-02-01 12:17:44.275 [Provider] C:\Windows\system32\ServerManager\Cache\CbsUpdateState.bin does not exist.
10280: 2010-02-01 12:17:44.275 [CBS] IsCacheStillGood: False.
10280: 2010-02-01 12:17:44.276 [CBS] CreateSessionAndPackage: begin
10280: 2010-02-01 12:17:44.788 [CBS] Error (Id=0) Function: 'CreateSessionAndPackage()->Session_OpenPackage' failed: 800b0100 (-2146762496)
10280: 2010-02-01 12:17:44.954 [ExceptionHandler] Error (Id=0) An unexpected exception was found:
System.Runtime.InteropServices.COMException (0x800B0100): No signature was present in the subject. (Exception from HRESULT: 0x800B0100)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at Microsoft.Windows.ServerManager.ComponentInstaller.CreateSessionAndPackage(IntPtr& session, IntPtr& package)
at Microsoft.Windows.ServerManager.ComponentInstaller.InitializeUpdateInfo()
at Microsoft.Windows.ServerManager.ComponentInstaller.Initialize()
at Microsoft.Windows.ServerManager.Common.Provider.Initialize(DocumentCollection documents)
at Microsoft.Windows.ServerManager.ServerManagerModel.InternalRefreshModelResult(Object state)




This wasn't very useful...

I then checked the CBS logs (%windir%\logs\cbs\cbs.log):

Throughout the log file in random locations it kept repeating:

Mark store corruption flag because of package: Package_for_KB973037~31bf3856ad364e35~amd64~~6.0.1.0. hr: 0x800b0100


I then went and downloaded the "System Update Readiness Tool" which checks the CBS component corruption. After it finished running it dumps its results to C:\Windows\logs\CBSCheckSUR.log. In this log file it also mentioned the same KB article as the corrupt one above:

=================================
Checking System Update Readiness.
Version 6.0.6001.22275
2010-06-21 11:06

Checking Deployment Packages

Checking Package Manifests and catalogs.

Checking package watchlist.

Checking component watchlist.

Checking packages.
(f) CBS MUM Missing 0x00000002 servicing\packages\Package_for_KB973037~31bf3856ad364e35~amd64~~6.0.1.0.mum

Checking component store

Checking SMI Store
Summary:
Milliseconds: 943738
Found 1 errors
CBS MUM Missing Total Count: 1




It was now determined that the cause of the issue was from microsoft update KB973037. I went and manually downloaded the update from:

http://www.microsoft.com/downloads/details.aspx?familyid=17F5F9E0-5869-41DA-9B3B-6E67540AF1F0&displaylang=en

I renamed the .msu file to .cab to allow me to extract it. Inside the extraced file there was another .cab file Windows6.0-KB973037-x64.cab which I had to extract. The file Package_for_KB973037~31bf3856ad364e35~amd64~~6.0.1.0.mum did not exist in the directory!

As a result I had to rename the update.cat and update.mum files in the extracted directory to:
Package_for_KB973037~31bf3856ad364e35~amd64~~6.0.1.0.mum
Package_for_KB973037~31bf3856ad364e35~amd64~~6.0.1.0.cat

These renamed files need to be copied to:

C:\Windows\servicing\Packages

However by default Administrators does not have access to this folder as all installations are done by the user account "TrustedInstaller". This is because standard user accounts can also install updates (if you allow them to with group policy). To give administrators full control take ownership of the packages folder, set permissions to full control, then give folder ownership back to TrustedInstaller! This is important - if "NT SERVICE\TrustedInstaller" is not owner updates can fail to install.

Now that you have access, copy the two files you renamed into this directory.

Try and open Server Manager.

Saturday, June 19, 2010

Exchange 2010 Role Based Access Control

In previous versions of Exchange such as 2000/2003 and 2007 the permissions were all done using ACLs (Access Control Lists). ACL's create many challenges when modifying permissions on mailboxes and active directory attributes especially when upgrading exchange versions, you need to ensure ACL modifications are maintained. Also troubleshooting problems that occurred due to ACLs being used in a nonstandard way can be very time consuming. Large enterprise companies needed to modify ACL's to keep their delegation of administrative structure in place.

In Exchange 2010 the Microsoft Exchange Team has completely changed the way the permission structure works. We now have whats called RBAC (Role Based Access Control). RBAC enables you to more closely align the roles you assign to users and administrators to the actual roles they hold within your organization without having to modify ACL's!

There are 7 core components you need to understand in RBAC:
- Management Role Groups
- Management Roles
- Management Role Entries
- Management Role Assignments
- Management Role Scopes
- Management Role Assignment Policies
- Direct User Role Assignment

Management Role Groups

Management role groups associate management roles with groups of administrators or specialist users. There are pre-defined Management role groups that come with Exchange 2010, and ones you can create yourselves. An example of a management role group is the Discovery Management RBAC role group, one that is used to grant users the ability to use the Multi-Mailbox Search feature.

Management role groups are actually "Special Universal Security Groups (USG)". They can contain many different types of nested objects such as:
- Users
- Mailboxes
- USGs
- Other Role Groups

Management Roles

Management roles are used to define a list of tasks that can be performed. Tasks can include things like powershell cmdlets, scripts, or special permissions that enable a specific task to be performed.

Management roles can be be used by multiple management role groups through the use of management role assignments.

Management Role Entries

Management Role Entries are individual entries on a management role that determine what cmdlets and parameters are available to the management role. Each role entry consists of only a single cmdlet (and associated parameters), script or special permission enabled to perform a specific task.

There are loads of pre-made management role entries with Exchange 2010 such as:
- MyBaseOptions
- MyContactInformation
- MyVoiceMail
- MyRetentionPolicies
- ResetPassword

The list goes on for ages... these are the default ones for the default Management Role Assignment Policy which you will read about below.

When creating a management role you select a whole bunch of management role entries.

Management Role Assignments

Management Role Assignments are the things that link the roles to the groups. By Assigning a role to a role group, this grants members of the role group the ability to use the cmdlets and parameters defined in the role.

Management Role Assignments are linked directly to the roles.

Assignments <--linked--> Roles

Role Assignments can also be linked directly to user accounts, they do not always have to be linked to a Management Role Group.

A role assignee is a role group, role assignment policy, a user, or a universal security group (USG). Management Role Assignment objects contain one or more of these role assignees.

By default only the Organization Management role group has the ability to assign roles and other role assignees. Only the user that installed Exchange 2010 is a member of the Organization Management role group by default. You can, however, add other users to this role group as needed, or create other role groups and assign delegate role assignment to those groups. I recommend adding in Domain Admins into the Organization Management role group for each domain in your forest. Delegating role assignments enables role assignees to delegate management roles to other role assignees.

Management Role Scopes

Management Role Scopes limit what parts of the of an exchange organisation can be managed by management role assignment. For example you may only want a role group to administer group memberships of a bunch of distribution groups in a particular organisational unit in a certain domain, instead of allowing them the ability to administer permissions on every distribution group in a forest. Also you may only want some users to be able to delete and create mailboxes on a particular server, or a particular DAG. Scopes can consist of things such as servers, organisational units, and filters on active directory objects.

Note: Management Role Scopes are linked to the Management Role Assignments!

Management Role Assignment Policies

Management Role Assignment Policies are collections of one or more end-user management roles that enables end users to manage their own mailbox and distribution group configuration. Role assignment policies enable you to control which specific mailbox and distribution group configuration settings your end users can modify. Different groups of users can have different role assignment policies specialized to them. The default role assignment policy that comes with Exchange 2010 allows users to configure their voice mail, setup retention policies, reset their password and change their address information. However you may want to extend this, for example you may want users by default to be able to send SMS text messages.

Role Assignment Policies need to be linked to Role Assignments.

Management Role <--linked--> Management Role Assignment <--linked--> Management Role Assignment Policy

What a role assignment policy does is automatically assign role assignments (which are then linked to management roles) to users mailboxes upon creation. Think of "Email Address Policies", they automatically set the user up with a standard email address upon creation. If you want to change your users email address convention across the board, you can simply modify your email address policy. You can also have multiple email address policies linking to different user's with different needs by using filters. Same thing applies with management role assignment policies! You can also prevent any role assignment policies from being assigned whenever creating a mailbox - something I do not recommend as it will increase the amount of administration and leave room for error when setting up new users.

If you want to change what roles are assigned to role assignment policies, you need to change the role assignments that link the role assignment policy to the roles. Unless the assignments built into Exchange 2010 don't suit your needs, you won't have to change these assignments.

As mentioned earlier, with management role assignment policies they only provide configuration settings for users to be able to modify their own exchange specific attributes for example items on their mailbox. Because of this, you may have guessed when creating a role assignment between a role assignment policy and a management role, you cannot specify a scope! A predefined scope ACL is set, either "SELF" or "MYGAL" depending on the particular management role its applying to.

There are two types of role assignment policies in Exchange 2010:
- Default Role Assignment Policy
- Explicit Role Assignment Policy

Default Role Assignment Policy

A default role assignment policy is the one automatically assigned to a mailbox when it is created or moved to a server running Exchange 2010, and the role assignment policy awasnt provided using the RoleAssignmentPolicy parameter on the New-Mailbox or Enable-Mailbox cmdlets.

Exchange 2010 includes a default role assignment policy that provides end users with the permissions most commonly used. You can change the default permissions on the default role assignment policy by adding and removing management roles to or from it.

If you want to replace the built-in default role assignment policy with your own default role assignment policy, you can use the Set-RoleAssignmentPolicy cmdlet to select the new default. When you do this, any new mailboxes are assigned to the role assignment policy you specified by default if you don't explicitly specify a role assignment policy.

When you change the default role assignment policy, mailboxes assigned the default role assignment policy aren't automatically assigned the new default role assignment policy. If you want to update previously created mailboxes to use the role assignment policy you've set as default, you must use the Set-Mailbox cmdlet to do so. You can always pipe to do all of them, eg Get-Mailbox Set-Mailbox.

Explicit Role Assignment Policy

An explicit role assignment policy is a policy that you assign to a mailbox manually using the RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox or Enable-Mailbox cmdlets. When you assign an explicit role assignment policy, the new policy takes effect immediately and replaces any previously assigned explicit role assignment policies.

Direct User Role Assignment

Direct user role is an advanced method for assigning management roles directly to a user or universal security group (USG) without using a role group or role assignment policy. Direct role assignments can be useful when you need to provide a granular set of permissions to a specific user and no other.

Using direct role assignments will significantly increase the complexity of your security model. If a user changes jobs or leaves the company, you will need to manually remove the assignments and add them to the new employee. I strongly recommend you never use Direct User Role Assignment and you always go down the path of management role groups and management role assignments. I really don't know why the Microsoft Exchange Team included this feature - maybe for Small Business, but I can see it causing complications in the enterprise organisations!

Role Based Access Control Diagram

I put together a diagram illustrating how it the components fit together. Please not that this diagram does not depict direct user role assignment.



Role Based Access Control Summary

Some key points I want you to take away with you from this:

- One or more administrators/users can be a member of a role group.

- One administrator/user can be a member of more then one role group.

- The role group is assigned one or more role assignments. These link the role group with one or more administrative roles that define what tasks can be performed.

- The role assignments can contain management scopes that define where the users of the role groups can perform actions. The scope determines where the users of the role group can modify configuration.

- One or more users can be associated with a role assignment policy.

- A role assignment policy is assigned to one or more role assignments. These link the role assignment policies with one or more end-user roles. The end-user roles define what the user can configure on his or her mailbox.

- The role assignments between role assignment policies and roles have built-in scopes that restrict the scope of assignments to the user's own mailbox or distribution groups.

- A role assignment can be created directly between a user or USG and one or more roles. The role defines what tasks the user or USG can perform. The role assignment can contain management scopes that define where the user or USG can perform actions. The scopes determine where the user or USG can modify configuration.

- Role assignment policies can't be assigned delegated role assignments.

Wednesday, June 16, 2010

Debug Logging for Folder Redirection

In addition to logging events in the Application Event log, Folder Redirection can provide a detailed log to aid troubleshooting. To create a detailed log file for folder redirection, use the following registry key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics

Set: FdeployDebugLevel = Reg_DWORD 0x0f

Note The log file can be found at: %windir%\debug\usermode\fdeploy.log

In pre-Vista versions of Windows, doing this will create the diagnostic log file %windir%\Debug\UserMode\fdeploy.log. For Vista, 2008 and Windows 7 however, doing this simply adds more detailed info to the event log.

Saturday, June 12, 2010

How to Enable Mailtips In Exchange 2010

If you are not up to speed on Mailtips I suggest you reading this article by the MS Exchange Team:

http://msexchangeteam.com/archive/2009/04/28/451193.aspx

To enable Mail Tips you need to use powershell with the Set-OrganizationConfig cmdlet. There are various components of mailtips you can enable or disable.

- MailTipsAllTipsEnabled. Controls whether MailTips are enabled. The default is $True.

- MailTipsExternalRecipientTipsEnabled. Controls whether MailTips for external recipients are enabled. The default is $False. External recipients are determined by reference to the accepted domains list. Any domain in this list is deemed internal; any other domain is deemed external.

- MailTipsGroupMetricsEnabled. Controls whether MailTips that depend on group sizes are enabled. The default is $True.

- MailTipsLargeAudienceThreshold. Controls the threshold for the number of recipients on a message before MailTips flags it as large. The default value is 25. This value is probably too low for large organizations, where big distribution groups are common. In this scenario, it makes sense to increase the value to 50 to stop MailTips from nagging users for no good reason.

- MailTipsMailboxSourcedTipsEnabled. Controls whether MailTips that depend on mailbox data such as out-of-office notices are enabled. The default is $True

Note: If all are enabled, it will increase load on your client access servers by 5%.

Monday, June 7, 2010

vssadmin - Microsoft Exchange Writer is Missing

I had a server that had the "Microsoft Exchange Writer" missing. When typing the following command from a command prompt all the VSS (Volume Shadow Copy) writers would come up besides the "Microsoft Exchange Writer".

"vssadmin list writers"

This is what the Microsoft Exchange Writer looks like should it come up:



If it does not come up in the list... to enable it navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Modify the "Disable Exchange Writer" registry key to a value of 0.

After this restart the "Exchange Information Store" service.

"vssadmin list writers" should now display the writer correctly.

Saturday, June 5, 2010

Exchange 2010 DAG Routing and CAS High Availability

In this blog post I wish to run through two key areas most Exchange Administrators do not know or have not come across with Exchange 2010. These are in my eyes, limitations in the product and need to be taken into close consideration when planning an Exchange 2010 enterprise infrastructure. As they are limitations to the product, it has not been documented very well by Microsoft and supporting Exchange communities.

Below we will cover:
- Database Availability Groups Routing
- CAS High Availability for Remote Sites

DAG Routing

For those of you who are not up to speed on Exchange 2010 Database Availability Groups I highly suggest you read my blog post on Exchange 2010 Database Mobility.

http://clintboessen.blogspot.com/2009/08/exchange-2010-database-mobility.html

As I illustrated previously, up to 16 servers can be a member of a DAG. Exchange mailbox servers have their own replication engine for replicating database transaction logs between servers running on TCP 64327 by default (can be changed). However there is no logic between this replication - take the following diagram for example.



Here is a DAG with only a single mailbox database. A passive copy of this database lies in every remote site. With DAG replication there is no smarts, there is no bridgehead server, no way of optimising which way replication traffic should go. The active mailbox database MDDB01 lies in London. This database is replicated everywhere. It needs to get to both Russia and Germany. Instead of copying it from London to Russia then Russia to Germany, it will copy it from London to Russia then London to Germany meaning the replication traffic needs to pass over the London to Russia path twice! This is something they may improve in the next version of exchange.

You can enable "encryption" and "compression" of replication traffic using powershell... the compression can help a little keeping bandwidth down.

CAS High Availability for Remote Sites

In Exchange 2010 your outlook clients talk to a Client Access Server for MAPI connectivity. The CAS then passes the requests on to the mailbox server. When you open outlook for the first time, Autodiscover will setup your outlook profile providing you with the closest CAS server to where your mailbox resides. These can be CAS Arrays, A bunch of CAS servers in a load balanced scenario.

What happens if you have a remote site with a single all in one exchange box running Mailbox, Hub Transport and Client Access roles that's a member of DAG replication for backup and off site recovery, and that server failed. Would users automatically fail over? The answer here is no. The reason being is because the DNS name they are pointing to is the local CAS server in that site, which in this instance is not highly available. The CAS server must be a member of a CAS Array to achieve automatic high availability. However saying this, the mailbox database is still online, as the next site in the priority list holding the passive copy has now become active. If the outlook clients changed their exchange server address to another CAS server in the organisation that is online, they will be able to get onto their email! Note that Outlook Anywhere/Outlook Web Access and Active Sync will always be highly available.

Thursday, June 3, 2010

Exchange 2003 Disk Failure - Restore Mailbox Database

I had an exchange 2003 server connected to a SAN using fibre channel. The LUN containing the mailbox database failed. When opening system manager and clicking on the storage group, the following error pops up:

An unknown error has occured.
ID no: 80040d1b
Exchange System Manager



First before you perform the restore you must perform the following steps:

Deleted the Reg Keys
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Applications\ExchangeServer_ServerName
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\CatalogNames\ExchangeServer_ServerName
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Databases\ExchangeServer_ServerName
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Gather\ExchangeServer_ServerName
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Gathering Manager\Applications\ExchangeServer_ServerName
HKEY_LOCAL_MACHINE\Software\Microsoft\Search\1.0\Indexer\ExchangeServer_ServerName

then Started Exchange Setup Recovery:
:\setup\i386\setup.exe /disasterrecovery

Lastly reinstall Exchange 2003 Service Pack 2

The Exchange Setup Disaster Recovery gets the server ready for recovering the entire exchange mailbox database.

At this point you can restore the exchange mailbox database using NTBackup or other methods. In this environment I am using Symantec Backup Exec. For instructions on how to perform the restore using Symantec Backup Exec please see:

http://www.billthecomputerguy.com/itsupport/Disaster%20Recovery/Backup%20Exec%20Disaster%20Recovery%20for%20Exchange%202000%20or%202003.doc