Friday, 13 August 2010

"You do not have permission to change your password"

I haven’t posted anything in a while, sorry about that. I’ll try to post more often. :-)

We had a call recently regarding users changing their expired password whilst logging on to a computer attached to another domain. Unfortunately or fortunately, depending on which way you look at it, almost all of our clients are Windows XP, so our initial response to these sort of queries is to ask the Local IT Administrator to fully patch the client experiencing the problem. Taking an XP client to SP3 usually solves most of the problems listed on TechNet for this particular error.

Unfortunately, patching didn’t work in this instance, and we weren’t sure why this was happening, so we logged a call with Premier Support. One of the articles we had missed in our initial investigations was highlighted to us by Microsoft -

The article explained that we needed to reverse a change that was made on our Domain Controllers by the application of Server 2003 Service Pack 1 that had cleared the list of Pipes configured on the “Network Access: Named pipes that can be accessed anonymously” property in our Default Domain Controllers Policy. The article explains that we should enable the new defaults introduced in Windows Server 2003 SP1 (COMNAP, COMNODE, SQL\QUERY, SPOOLSS, LLSRPC, BROWSER, NETLOGON, Lsarpc, samr) for that property to restore the ability for users logging on to a computer from another domain to change their password when it has expired.

The reason this happens is because an expired password prompt on a client appears before a user has actually logged on. To change the password at this point, a computer from another domain has to open a null session with a domain controller in the domain of the user, using an Anonymous connection to those named pipes that were removed with the installation of SP1.

You may ask, why I’m posting about this when it’s already detailed in the TechNet article above. Not entirely happy that we would enable anonymous access to all of the Named Pipes listed in the article, we asked Microsoft to identify specifically what Pipes we needed to enable to resolve the issue regarding changing expired passwords from computers on other domains. They came back to us with only two Pipes that needed to be enabled, LSARPC and SAMR.

These Named Pipes that allowed null sessions, have specific vulnerabilities and exploits that exist, hence the reason for their removal by Microsoft. In the end we decided not to make the change and migrate the affected computers to the users domain, but i thought it would be interesting to share that you didn’t need to allow anonymous access to all the named pipes detailed in the article above, if you need to make this work, you can now do it with as little risk as possible.

Wednesday, 26 May 2010

Delay on Enterprise Vault Web Pages on first access each day.

After deploying a geographically dispersed cluster toward the end of last year, the next thing on my to do list, was to provide archiving services.

We use Symantec Enterprise Vault across the organisation, so I set about installing and configuring that. The installation went smoothly and all was working without any major issues.

The only issue reported by users was in regard to the search and browse vault web pages, usually viewed through Outlook were taking a long time to load for the first attempt each day.

I called Symantec Support and was pointed in the direction of the article below.

In our case this didn’t apply. This article ( was closer to our solution, but still not our complete solution.

The runtime config below will be familiar to admins who run Exchange 2007 Servers where no internet access is available. For those who are not familiar with certificate signed code, at regular intervals a certificate revocation list will be checked to see if the certificate has been revoked. Where no internet access is available the delay occurs as the server attempts the connection anyway.

Symantec advised us to place the following inside the runtime tags inside the machine.config file. The reason this is different from the latter support article above is because were running the server on Windows 2008.

     <generatePublisherEvidence enabled="false"/>

This solved our delays nicely.

Monday, 24 May 2010

Convert Linked Mailboxes to User Mailboxes in Bulk

My organisation has gone through a massive migration project to unify Active Directories and Exchange organisations. As a result of these migrations a lot of mailbox migrations have resulted in a lot of mailboxes ending up as linked mailboxes even though their not.

The official TechNet article on this explains how to disconnect the mailbox and re-attach it to the user account correctly as a user mailbox.

Another way to make this appear to be corrected is to manually change the “Recipient Type” AD property on the affected mailboxes. This though, is unsupported.

Using the official method from Microsoft results in the loss of any specific mailbox information such as SMTP, x400 & x500 addresses, mailbox sizes and any other individual mailbox settings.

Only e-mail addresses and mailbox sizes were important to me (I must admit, I forgot about mailbox sizes at first).

I came up with the script below that would properly convert all Linked Mailboxes on a particular server to user mailboxes in a supported way. The script is very effective, but you will want to check out the list of considerations below before running it, they might lead you to amend the script slightly. You will have to modify the $exchangeserver and $userdomain variables though.

$exchangeserver = "exchccr1"
$userdomain = "domain\"

$linkedmailboxes = get-mailbox -server $exchangeserver -resultsize unlimited|where {$_.recipienttypedetails -eq "LinkedMailbox"}

foreach ($mailbox in $linkedmailboxes){
Disable-Mailbox -Identity $mailbox.displayname -confirm:$false

Get-MailboxDatabase -server $exchangeserver|Clean-MailboxDatabase

start-sleep -s 90

foreach ($mailbox in $linkedmailboxes){
$usernamestring = $userdomain + $mailbox.samaccountname
Connect-Mailbox -Identity $mailbox.exchangeguid -Database $mailbox.database -User $usernamestring
set-mailbox -identity $mailbox.displayname -emailaddresses $mailbox.emailaddresses

start-sleep -s 90

foreach ($mailbox in $linkedmailboxes){
set-mailbox -identity $mailbox.displayname -EmailAddressPolicyEnabled $mailbox.EmailAddressPolicyEnabled -emailaddresses $mailbox.emailaddresses -UseDatabaseQuotaDefaults $mailbox.UseDatabaseQuotaDefaults -ProhibitSendQuota $mailbox.ProhibitSendQuota -ProhibitSendReceiveQuota $mailbox.ProhibitSendReceiveQuota -IssueWarningQuota $mailbox.IssueWarningQuota

Some things to consider…

  • The filter on this script doesn’t consider legitimate linked mailboxes.
  • Only E-Mail addresses and mailbox sizes are re-applied to the freshly attached mailbox. More can be added to the script though.
  • You can’t attach a mailbox to a disabled account. The script won’t stop, but will error on disabled user accounts.
  • Don’t stop the script as it’s running, even if it’s choosing the wrong selection of accounts. It will mean more manual work after if you do.
  • Ensure you have "Exchange Server Administrator" permissions on the server you wish to run this script.
  • Ensure you have permissions to run the Clean-MailboxDatabase permissions on the server you wish to run this script (You don't get this by default with "Exchange Sever Administrator" permissions). If you're an admin in my 0rg, we can give you this permission if you if you don't have it already.

There you go, a script that will do all your linked mailboxes in one go. I’ve not been able to find another online, so I hope this helps you.

Monday, 17 May 2010

Upgrading Delegated Exchange 2007 Clusters to SP2 - FIX

Concerning a previous post “Upgrading Exchange 2007 Clusters to SP2 – Workaround”, Microsoft provided a fix for the issue of upgrading an Exchange 2007 Cluster using delegated privileges.

Microsoft provided us with a fix that allows this to happen without using the workaround described in the article above.

Download the file from here

How to use the XML…

  1. Copy all the E12SP2 setup files to local disk.
  2. Replace the original ExBPA.PreReqs.xml with the one available above.
  3. Run the setup from local disk.

Tuesday, 19 January 2010

Exchange 2007 Public Folder Mail Routing

We had a report recently that mail from outside the Exchange organisation destined for Public Folders was being returned in the form of an NDR, but all other mail was flowing fine.

To explain the problem, here’s a little background about the Exchange 2007 topology. We have two HUB servers that handle mail heading inbound and outbound of the organisation. Beneath that we have a lots of exchange deployments at physical sites with varying local configurations. To complicate things we have firewalls sat in front of these other deployments with some more strict than others. As we add more exchange deployments it can be a considerable task getting these firewalls adjusted to allow the new hub transport servers to communicate with the old, usually leading local administrators to notice queues forming on their sites.

I had all the information I needed to track the messages, so started by tracking the message at our two hub transports handling mail into and out of the system. The Public Folder that the message was being delivered to, only had one replica. I discovered that the message was being sent to what seemed to be a completely random hub server, not to the site where the replica existed. The messages were queuing there as the complaining administrators hadn’t opened their firewalls as requested. Fine I thought, get them to open the firewalls properly, but I wanted to figure out why the message was being sent to this strange server in the first place.

The answer lay in the following Microsoft TechNet Article -

The article explains how messages are routed for public folders. The start of our problems were because that our two Hub Servers that were receiving mail from the internet didn’t have a copy of the Public Folder Hierarchy to know where to route the message, in this instance it will look at the values of msExchOwningPFTreeBL a property of CN=Public Folders,CN=Folder Hierarchies,CN=First Administrative Group,CN=Administrative Groups,CN=Cymru,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cymru,DC=nhs,DC=uk . All of the public folder stores should be listed in that property and the Exchange 2007 SP1 or SP2 categoriser filters them out in the following way…

1. Ranking by the age of the public folder database   By default, public folder databases that have an age threshold of less than two days are not considered unless the age of all public folder databases is less than the threshold or the age is unknown.

2. Proximity   The local server is preferred. If the local server does not contain a replica of the public folder database, a server in the same Active Directory site is preferred. If the local Active Directory site does not contain a replica of the public folder database, a server in a remote Active Directory site or routing group is selected as the preferred destination.

3. Cost   If more than one remote Active Directory site or routing group contains a replica of the public folder database, the server in the Active Directory site or routing group that has the least cost routing path from the local Active Directory site is selected as the preferred destination.

In the long term, I’d want the messages routed directly from our two entry point Hub Servers, but in the short term point 1 stopped us from just creating a Public Folder Database to store only the Hierarchy for routing purposes, two days might have been a problem. I created the databases anyway.

Our AD site layout is fairly simple , its a snowflake design where all of the AD sites with connections to our central site had all the same costs. The quick way to resolve this was to drop the cost of a site where you wanted these messages to be routed via, this solved the problem short term until the mandatory two days expired until the newly created PF Databases could route the messages itself.

OR the local admin could have opened the firewalls properly, but that would have been too easy. :-)