We’ve been working on some major upgrades to our Exchange environment over the last while. During the course of that, we started receiving NDR’s for messages sent to mail-enabled public folders. Initially, these were “MapiExceptionNotAuthorized” messages, which are related to permissions. Those were sorted out without too much trouble, as the NDR is at least somewhat descriptive. But then we started receiving a very generic NDR of
#550 4.4.7 QUEUE.Expired; message expired ##.
…not really much to go on. Exchange 2007 does give some more “in plain English, please!” information in its NDR’s, but that also wasn’t much help:
Delivery has failed to these recipients or distribution lists:
[user display name]
Microsoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator.
Wow…that was helpful…
On a recent network audit for a prospective new client, I came across an issue in the Exchange System Manager for their Exchange Server 2003 box. When you tried to browse into any public folder management, ESM presented the following error:
The SSL certificate server name is incorrect. Read more…
Lately, our company has started developing user web portals for our clients. The main goal is to provide a central reference point for common links (webmail, helpdesk, remote assistance links … ), howto documents, and other files and resources. A secondary goal was to also allow user administrators to perform basic user management through a web interface. This would include things like disabling/creating/unlocking user accounts, resetting passwords, and modifying group memberships for access reasons. Myself and the other admin tasked with setting up this portal are most familiar with PHP, and so we went of looking for the best means of interfacing with Active Directory through PHP. Read more…
We recently received reports of message delivery delays in our Exchange organization. We run Exchange 2007, so I checked out the Hub Transport Servers and discovered that messages were piling up in the Submission queues on both of the main hub transports. Restarting the Microsoft Exchange Transport service didn’t get things going again, so I turned to the Application Log to try to figure out what was going on. Read more…
Part I demonstrated how to find aged or inactive accounts, and in Part II we will look at another lingering account type: disabled accounts.
Like inactive accounts, Directory Searchers also come in handy for disabled accounts. We can also, however, read an Active Directory account’s status directly from a hidden attribute on the ADSI object. Let’s start with the Directory Searcher method. This entry also draws from Bahram’s Blog. The code:
$adobjroot = [adsi]''
$objdisabsearcher = New-Object System.DirectoryServices.DirectorySearcher($adobjroot)
$objdisabsearcher.filter = "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1135188.8.131.523:=2))"
$resultdisabaccn = $objdisabsearcher.findall() | sort path
We’ll start off with Inactive accounts first, and then work on the disabled accounts after that.
Active Directory in Server 2003 has a nice user/computer attribute called lastLogonTimeStamp that can help us keep track of inactive accounts. If you have ever tried to use that attribute, however, you might have come up with something like this…
As part of our process to disable user accounts, we take ownership of the user’s server-stored documents such as roaming profiles and redirected My Documents directories. We then either keep access restricted to the domain admins group or grant access to a replacement user who should receive access to the departed user’s files.
With an upgrade to Exchange 2007, we have taken advantage of the Powershell access to Exchange objects, and have scripted the mailbox provisioning and account disable processes. One of the sticking points in getting the disable script wrapped up was seizing control of the user’s directories. Now, Powershell does have the ability to modify ACL’s through the New-Acl and Set-Acl cmdlets (links below), but the users have exclusive access to their server-side directories. It is easy enough to take ownership of a directory through the Windows Explorer Security dialog, but the Powershell methods all presented some form of error when trying to set permissions or change ownership on a file system object to which you do not already have access to.