Wednesday, January 22, 2014

Moving Mailbox - Active Directory operation failed

When attempting to move a users mailbox from Exchange 2003 to Exchange 2010, the following error was experienced.

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00


Username
Failed

Error:
Active Directory operation failed on DC.domain.local. This error is not retriable. Additional information: Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150BC1, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0


The user has insufficient access rights.
Click here for help...
http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.3.169.1&t=exchgf1&e=ms.exch.err.Ex6AE46B
Warning:
When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting that Exchange not copy such items to the destination mailbox. At move completion, these corrupted items won't be available in the destination mailbox.


Exchange Management Shell command attempted:
'domain.local\users\username' | New-MoveRequest -TargetDatabase 'MailboxDatabase4' -BadItemLimit '10'

Elapsed Time: 00:00:00


The problem was caused by incorrect permissions on the AD user account.  Re-enabling "inherit permissions" on the user account resolved the issue.
 
 

Sunday, January 19, 2014

"Try Next Closest Site" Group Policy Setting

In a previous post I wrote about how the DC Locator component of Windows locates a domain controller.  This post can be found on the following URL:

http://clintboessen.blogspot.com.au/2010/05/how-clients-locate-domain-controllers.html

In this post we are going to look at a feature called "Try Next Closest Site" which is enabled on Windows Vista upwards clients via Group Policy.

In Windows 2000/XP/2003 when all domain controllers in an Active Directory site fail, there is a chance workstations may failover to another Active Directory site at a higher cost then the most preferable one as defined in Active Directory Sites and Services.  Changes have been made to the DC Locator algorithm starting from Windows Vista/2008 Server onwards which improves the DC Locator algorithm to ensure workstations always communicate with the next closest Active Directory site as defined in Sites and Services.

I strongly recommend this setting always be configured if your workstations are Windows Vista or higher.  To enable this setting perform the following.

1.Click Start, click Administrative Tools, and then click Group Policy Management.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.

3.Double-click Forest:forest_name, double-click Domains, and then double-click domain_name.

4.Right-click Default Domain Policy, and then click Edit.

5.In Group Policy Management Editor, in the console tree, go to Computer Configuration/Policies/Administrative Templates/System/Netlogon/DC Locator DNS Records.

6.In the details pane, double-click Try Next Closest Site, click Enabled, and then click OK.
For additional reading please see the following URLs:

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

Note: With "Try Next Closest Site" it will never try a remote site which contains a read only domain controller as read only domain controllers generally only store passwords for the users at the specific remote site for security reasons.

Wednesday, January 15, 2014

Distribution Groups - The properties on this object have invalid data.

I am in the process of carrying out another Exchange 2003 to Exchange 2010 migration for a customer with 800 users.  On the Exchange 2010 server, when attempting to open the properties of a distribution group which was created on Exchange 2003, the following message appears.

"The properties on this object have invalid data. If you click OK, the default values will be used instead and will be saved if you do not change them before hitting Apply or OK on the properties page. If you click cancel, the object will be displayed read-only and corrupted values will be retained."


This message can appear in a number of circumstances for any corrupt information on an Exchange 2010 distribution group.  To compare what is corrupt a trick is to do this:
  1. Create a new distribution group on Exchange 2010
  2. Look at the properties of the distribution group by typing Get-DistributionGroup "New Distribution Group" | fl
  3. Compare this against the properties of the bad distribution group Get-DistributionGroup "Bad Distribution Group" | fl
  4. Fix whatever invalid information exists on the bad distribution group.
In my case, the Distribution Group had spaces in the Alias.  The alias attribute must not contain spaces, after removing the spaces the error now longer displayed.

 

Tuesday, January 14, 2014

What are Scoped Send Connectors?

A topic which frequently confuses Exchange Administrators is the concept of "Scoped Send Connectors".  So what are they?

When you mark a send connector as scoped, this means it can only be used by Exchange 2007/2010 hub transport or Exchange 2013 mailbox servers in the same Active Directory site as the send connector.  If not selected, the connector can be used by all transport servers in the Exchange environment.

How do you determine what servers are in the Active Directory Site?  A Send Connector is not bound to any specific Active Directory site Clint, they are merely an object in Active Directory!

True, however say you have an Active Directory site called "Contoso HQ" and the site has 4 transport servers whether they be Exchange 2010 Hub Transport servers or Exchange 2013 mailbox servers.  Two of these servers are marked as source servers a of the scoped send connector and two aren't.  The two servers which are a member as a source server of the send connector can obviously use the send connector.  The other two transport servers in the same Active Directory site which are not source servers can also use the scoped send connector, all other transport servers in other sites - bad luck!

Unmarking it as scoped means transport servers in other sites can relay through the send connector if there is no closer option for external mail relay.

Hope this blog post brings clarification to this topic.

How to Enable Group Policy Debugging on Windows 7 / 8 Clients

In Windows XP / 2003 there was a very useful log file called "Userenv.log" which was located under %Systemroot%\Debug\UserMode\Userenv.log.  This log file was extremely happy when diagnosing issues relating to Group Policy.

This log file no longer exists in Windows 7 / Windows 8 and Microsoft has moved majority of the Group Policy logging to the new "Applications and Services Logs" under Group Policy\Operational.  The only caveat however from my experience is these logs are no where near as verbose as the logs provided under the legacy Userenv.log.

You can however enable verbose logging on Windows 7 / Windows 8 computers by adding an additional registry key, this procedure however has not been documented officially by Microsoft on TechNet and should be used for advanced troubleshooting only as a last resort.

The registry key which turns on advanced verbose logging is as follows.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics]
"GPSvcDebugLevel"=dword:00030002


The resulting log file “gpsvc.log” can be found %WINDIR%\debug\usermode.
Hope this post assists you in whatever group policy troubleshooting your currently performing!

Sunday, January 12, 2014

Direct Access Client Connectivity Issue

I have implemented Microsoft Direct Access for a customer running Windows 7 Enterprise and Windows 8 Enterprise workstations.  Direct Access was tested in a working order however the customer has a number of laptops which are unable to connect to the Direct Access service.

The following commands were run to gather diagnostic information about the issue:

netsh interface httpstunnel show interfaces

Role: client
URL: https://vpn.example.com:443/IPHTTPS
Last Error Code: 0x2af9
Interface Status: failed to connect to the IPHTTPS server.  Waiting to reconnect

Get-DAConnectionStatus

Status: Error
Substatus: CouldNotContactDirectAccessServer


This error was caused by a proxy server set on the workstations in question in Internet Explorer.  When a proxy is set, Direct Access will attempt to create the IPHTTPS connection through the proxy server.  If you want to leave proxy servers intact in Internet Explorer properties, what you can do is add vpn.example.com (the connection URL) as a proxy exception in Internet Options.

ODBC SQL Server Driver - Cannot Generate SSPI context

On the weekend I responded to an emergency callout regarding a custom Microsoft Access front end application not being able to talk to the backend SQL database.  The error which was being received was as follows.

Connection failed:
SQL State:'S1000'
SQL Server Error 0
[Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context


After investigation this was caused by an incorrect time set on the SQL server.  The Kerberos time tolerance by default is set 5 minutes however the SQL server clock had drifted 8 minutes out.  The customer did not have their Active Directory time hierarchy configured correctly.

Thursday, January 9, 2014

What is Name Resolution Policy Table (NRPT)

The NRPT is a new feature which was first introduced in Windows Server 2008 R2 that allows a client to assign a DNS server address to particular namespaces rather than to particular interfaces. The NRPT essentially stores a list of name resolution rules that are applied to clients through Group Policy.  Each rule defines a DNS namespace and DNS client behaviour for that namespace.

This feature is essential to support new features of Windows such as Microsoft Direct Access.

When a DirectAccess client is on the Internet, each name query request is compared against the namespace rules stored in the NRPT. If a match is found, the request is processed according to the settings in the NRPT rule. The settings determine the DNS servers to which each request will be sent.

For more information about NRPT, please view the following TechNet website:

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

Wednesday, January 8, 2014

Licensing Windows Server 2012 or Windows 8 with KMS

In previous releases of Windows such as 2008 and Windows 7 you can install Windows without entering a product key.  After the installation is complete, the computer would automatically find the KMS through DNS and license/activate itself against the KMS server.

In Windows Server 2012, it asks for a product key as part of the installation process as shown in the following screenshot.


The only way to progress this screen is to enter a MAK key obtained of a companies Microsoft licensing portal.

So what happens if you want the Windows 2012 Server or Windows 8 machine to automatically license itself against a KMS upon completion of the installation?  You can't enter a product key here as this means the machine will become a MAK license.

The answer is to use a KMS Client Setup Key.  This isn't the KMS key itself, but a key which tells the Windows Server 2012 or Windows 8 machine that once it finishes installation to go off and license itself against a KMS.

Microsoft has published a list of KMS Client Setup Keys on the following TechNet article.  Simply enter the correct KMS Client Setup Key to complete the installation in which Windows will go off and automatically activate against the appropriate KMS server through DNS or Active Directory discovery.

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

Hope this post has been helpful!

Tuesday, January 7, 2014

Windows 8.1 Internet Explorer 11 - This page can't be displayed for Google

A customer of mine flagged an interesting issue on Windows 8.1 running IE11.  Whenever they attempted to access "google.com" or any Google related page such as Google Maps they would receive an error stating "This page can't be displayed".  Upon refreshing the page, the page would then load normally.

Generally these symptoms relate to one of two issues:
  • The Maximum Transmission Unit (MTU) being set to something too high on the core switch/router
  • A DNS Issue where the DNS server is configured with a forwarder which is not responding in sufficient time or simply delaying on DNS resolution attempts.
These issues however effect ALL websites.  This issue was only isolated to Google related websites.

A little research and I stumped across the following website which illustrates the exact issue:

http://betanews.com/2013/10/19/google-is-broken-in-ie11-on-windows-8-1/

This website mentions that Google has recently made code changes to its website which effects the Internet Explorer 11 web browser.

The Work Around

Until Google or Microsoft sort these issues out between each other, the work around is to disable "Enhanced Protect Mode" through Internet Properties.  To do this perform the following procedure:

1. Click the Tools icon in Internet Explorer.
2. Go to Advanced tab and select the  Security section and uncheck the checkbox for Enable Enhanced Protected Mode (requires restarting Internet Explorer).
3. Click on Apply, and then click OK.
4. Close all open Internet Explorer windows, and then restart Internet Explorer.

 

Sunday, January 5, 2014

Windows Server 2012 DHCP Failover Not Adhering to Scope Times

When setting up Windows Server 2012 DHCP Failover you may notice the lease duration provided to clients may not adhere to the lease duration configured on the DHCP scope.  This is by design and a normal behaviour in a DHCP failover relationship.

By default when a lease is first issued to a client, it adheres to the Maximum Client Lead Time (MCLT) value, not the value on the DHCP scope.  This is considered a temporary lease period given by a failover server to a new client.  In addition to providing a temporary lease to client, it specifies the amount of time for which a DHCP lease may be renewed by either failover peer without contacting the other.  It also specifies the amount of time that either DHCP server will wait in a “partner down” state before assuming control of the entire IP address range within the scope.  ( default = 1 hour ).

Maximum Client Lead Time (MCLT) can be found when configuring DHCP failover in the following location in the setup wizard.

 
After the initial lease, when the client attempts to renew its IP address it will then inherit the default scope lease time.
 
Key points to take away:
  • Windows Server 2012 DHCP Failover, an initial lease always = the MCLT (Maximum Client Lead Time)
  • Afterwards the same client will renew and get whatever is defined in the scope definition.
So if you see clients receiving 1 hour leases from DHCP, relax its by design!  They will receive a full lease when they next attempt to renew DHCP.

Sources:

http://technet.microsoft.com/en-us/library/dn338973.aspx
http://tools.ietf.org/html/draft-ietf-dhc-failover-12#section-5.2
http://support.microsoft.com/kb/2831920

Naming Information cannot be located because: The directory or file cannot be created.

I just added the first Windows Server 2012 R2 domain controller to a 2008 Active Directory domain at a customer.  As soon as I added the first 2012 R2 domain controller to the new domain, when opening any of the Active Directory MMC Management consoles the following error was experienced.

Naming information cannot be located because:
The directory or file cannot be created.
Contact your system administrator to verify that your domain is properly configured and is currently online.


When performing a netdom query dc on the new domain controller it complained time is out.


Fixing up the time to ensure it is within 5 minutes of the PDC Emulator (as required for Kerberos) resolved the problem.

Easy one but had me stumped for a little while (I didn't glance at my system tray to check the clock until a while).

Thursday, January 2, 2014

Configure failover failed. Error: 20114: The DHCP Failover relationship already exists.

This post relates to the new Windows Server 2012 Failover technology.  I was diagnosing DHCP Issues at a customer when I was required to remove my DHCP scopes from failover configuration then re-add them.  After attempting to re-add the scopes I received the following error.

Configure failover failed.  Error: 20114: The DHCP Failover relationship already exists.


Despite removing the scopes from DHCP failover the partner server still believes the DHCP failover relationship was in existence.

After messing around a little longer I found out a work around.  The error was occurring because I was using the same Relationship Name as before.  Changing the Relationship Name to something else resolves the issue.

 

Exchange 2003 to Exchange 2010 Mailbox Move Failing

When attempting to perform mailbox moves between Exchange 2003 to Exchange 2010 the following error was experienced.

Mailbox Name
Failed


Error:
Mailbox database 'b70397e5-c347-4f7b-8a15-575172b89820' is offline.


MapiExceptionLogonFailed: Unable to make connection to the server. (hr=0x80040111, ec=1010)
Diagnostic context:

    ......
    Lid: 13720   dwParam: 0x6D9      Msg: EEInfo: Flags: 0
    Lid: 11672   dwParam: 0x6D9      Msg: EEInfo: NumberOfParameters: 4
    Lid: 8856    dwParam: 0x6D9      Msg: EEInfo: prm[0]: Unicode string: ncacn_ip_tcp
    Lid: 8856    dwParam: 0x6D9      Msg: EEInfo: prm[1]: Unicode string: cpaexch01.cpawa.com.au
    Lid: 12952   dwParam: 0x6D9      Msg: EEInfo: prm[2]: Long val: -545057711
    Lid: 12952   dwParam: 0x6D9      Msg: EEInfo: prm[3]: Long val: 382312662
    Lid: 45169   StoreEc: 0x824    
    Lid: 44273 
    Lid: 59431   EMSMDB.EcDoConnectEx called [length=99]
    Lid: 34855   EMSMDB.EcDoConnectEx returned [ec=0x3F2][length=56][latency=0]
    Lid: 56945 
    Lid: 59431   EMSMDB.EcDoConnectEx called [length=99]
    Lid: 34855   EMSMDB.EcDoConnectEx returned [ec=0x3F2][length=56][latency=15]
    Lid: 59505   StoreEc: 0x3F2    
    Lid: 52465   StoreEc: 0x3F2    
    Lid: 60065 
    Lid: 33777   StoreEc: 0x3F2    
    Lid: 59805 
    Lid: 52209   StoreEc: 0x3F2    
    Lid: 56583 
    Lid: 52487   StoreEc: 0x3F2    
    Lid: 19778 
    Lid: 27970   StoreEc: 0x3F2    
    Lid: 17730 
    Lid: 25922   StoreEc: 0x3F2    

Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.3.169.1&t=exchgf1&e=ms.exch.err.ExC2B9A8
Exchange Management Shell command attempted:
domain.local/Townsend/Users/Mailbox Name | New-MoveRequest -TargetDatabase 'MailboxDatabase2'

Elapsed Time: 00:00:01


After some investigation it turned out that the Exchange 2010 server did not have permissions to the Exchange 2003 mailbox databases.  To fix the issue I simply went to the properties of the Exchange 2003 mailbox database in System Manager, Added the Exchange 2010 computer object and granted it full control permissions.


After making this change mailbox moves worked successfully.