By: Aaron Steele
Posted:
October 8, 2008 at 2:23 PMAs a colleague recently discovered, losing your cell phone to a thief is a disheartening experience. If you ever find yourself in this situation, and in this case have had your smart phone (including an iPhone) connected to your companies Microsoft Exchange Server 2007 system you can find small amounts of solace in its ability to help you manage said device. It should be noted that recent revisions of BlackBerry handhelds, even without a BlackBerry Enterprise Server in your environment, can configure their device to sync over the air through BlackBerry Internet Services. These type of connections are not detected nor can they be controlled in the same way as a Windows Mobile or iPhone Active Sync style Over The Air (OTA) Connection. Lost/Stolen BlackBerry devices should be wiped by contacting your cell phone provider. To manage and potentially remotely wipe your device you should 1. Sign onto your companies Exchange 2007 OWA interface and select Options from the top bar. 
2. Then select Mobile Devices from the menu on the left 
3. In there you will see the different mobile devices that are setup to sync with your account, their status and it will give you the ability to remove that device's ability to sync, Wipe All data from it, and display the recovery password setup for that device. If you have multiple devices setup to sync over the air, you can disable/delete them individually. 
4. If you select "Wipe All Data from Device..." you will get prompted with a confirmation dialog 
5. Selecting OK will initiate the wipe, and then you should remove the device from your device list. It is recommended to perform this wipe before you contact your service provider because as soon as your provider disconnects it from the network you can no longer wipe it with this service. As a note, your friendly neighborhood Exchange Administrator has the same abilities as you do in control of your device, the same rules apply. If you've canceled your service through your cell phone provider and disabled the device via their customer service, wiping the device in this way will have no impact. The device has be on the network and able to be contacted by the Exchange Server for the remote wipe to happen. Enjoy, and I hope you don't have the misfortune of needing to wipe your phone.
By: Aaron Steele
Posted:
August 13, 2008 at 10:59 AMIn a recent encounter at a client I discovered that it might be handy for Exchange Administrative and Support staff to be configured such that their Outlook settings do not access or download the OAB. This means that they will always be looking directly at the GAL for their addresses, and will be sure to have an updated view of what is there, not contingent on the System Attendent to create an OAB on it's schedule.
The load on Domain controllers does go up, as these persons are making direct LDAP lookups for every address, but for the limited scope I think it is benefitial.
Microsoft Outlook 2003 is the platform I've configured for this. There are a few ways that Outlook downloads the OAB and it is also dependent on if you are running Outlook in Cached mode or not.
If you are not in Cached Mode, you can simply go into the send/receive group for your exchange server and uncheck the box to download the Address Book when you send receive the group.
You may also want to get rid of the Send/Recieve menu item for downloading the Address Book. The registry key to do this is HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\DisabledCmdBarItemsList and it is a string type key named TCID1 with a value set to 5658.
If you are running Outlook in cached mode it becomes slightly more complicated.
You have to create a few new registry keys as well as the work already done.
within the registry key
HKEY_CURRENT_USER\Software\Policies\Microsoft\Exchange\Exchange Provider create dword entries named:
Limit SRS Incremental Download
Limit Manual OAB Download
Limit SRS Full OAB Download
Allow SRS Full OAB Download
and set them all to dword:00000000.
Microsoft details these changes, as well as gives you some nice information about the OAB files and what they contain at the references below.
They also provide an as-is vbs script to make all the necessary registry changes.
References:
Hope this helps and helps your Service Desk staff in their quest to assist users.
By: Aaron Steele
Posted:
July 9, 2008 at 10:51 PMI ran into a 6 GB+ mailbox recently. And to boot, it had roughly 140,000 items in the inbox. Ponder that a little to yourself. What kind of impact do you think such a mailbox would have on your Exchange server? No matter how overbuilt it is, you'll notice that in terms of memory usage, disk usage, log file growth and undoubtedly other areas.
The next problem is, how do you deal with such a mailbox? If you try to interact with it, Outlook is bound to crash. Downloading said inbox into an OST would just kill a connection. Luckily for me OWA worked. It parsed the madness into 50 item chunks to view. Just deleting said items will generate a metric Ton of transaction logs, could crash your mailbox server if you aren't careful. I won't get into the process that was generating the mail, but leave it to be that said process would, if allowed, open each message and process then delete it. I would just have to configure permissions to allow said processing. The last thing about it would be that mail, if configured, would continue to flow into said mailbox, to be opened, processed and deleted.
Having discussions with some colleagues, it was suggested that we create a new storage group, on which we configure circular logging, and this mailbox would live in said SG. This solves the problem of transaction logs filing the drive and crashing the system and also enables a single DB that has to be managed in terms of grown and size and reclamation of unused space.
If we trust the process to remove content after processing, then we can forgo a mailbox policy to remove data after a period of time. If we don't trust the process, we must create and implement a managed folders policy on this mailbox.
A few things to mention:
- Exchange 2007 doesn't give you a graphical interface to see mailbox size across a server or even a storage group or for that matter a mailbox store. Many resource exist to find out what to do to get this data, but here is one I like, please watch line wrap and replace <server name> with your mailbox server.; 'Get-MailboxStatistics -server <servername>| Sort-Object TotalItemSize -Descending | ft DisplayName,@{label="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},ItemCount'
- When you do end up cleaning up this much mailbox data, be prepared to offline defragment the mailbox store that it used to be housed in. Microsoft reference for eseutil /d http://technet.microsoft.com/en-us/library/aa997972(EXCHG.80).aspx
- Be prepared to look at your exchange backup/archival solution and clean up any mess such a mailbox created.
I hope my knowledge helps you if you ever encounter such a mailbox.
By: Aaron Steele
Posted:
April 14, 2008 at 3:02 PMI got a query from a colleague today about how to edit custom AD attributes. The default ADUC (dsa.msc) will not display these attributes. A small caveat here; if you have the new Vista compatible Server 2008 based Remote Server Administration Tools (RSAT) you can edit these properties, and any other property in the directory directly from ADUC. I'll let the other bloggers out there talk about that and all of its glory.
Now, back to the issue at hand; multiple tools exist, from the basic ldp.exe to the highly complex (writing your own DLL to plug into ADUC), and all places in between. Most of the tools are free, but some offer you the ability to purchase a upgraded piece if you so desire.
I'll try to compare them here for your edification.
LdapBrowser by Softerra can be downloaded at http://download.softerra.com/files/ldapbrowser26.msi. Softerra describes it as "LDAP Browser is a lightweight version of LDAP Administrator with limited functionality."
Sysinternals (Microsoft) AD Explorer can be found at http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx. It is described as "Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. You can use AD Explorer to easily navigate an AD database, define favorite locations, view object properties and attributes without having to open dialog boxes, edit permissions, view an object's schema, and execute sophisticated searches that you can save and re-execute" by Bryce Cogswell and Mark Russinovich.
ADSIEdit.msc also by Microsoft is provided as part of the install of Windows Server 2003 Support Tools. Download can be found http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en. It is described as "This GUI tool is a Microsoft Management Console (MMC) snap-in that acts as a low-level editor for Active Directory. Network administrators can use Active Directory Service Interfaces (ADSI) for common administrative tasks such as adding, deleting, and moving objects with a directory service. Attributes for each object viewed can be changed or deleted."
If you are capable at command line scripting a tool like ADMod from www.joeware.net is invaluable. It would allow you to, once paired with ADFind, locate and modify just about any attribute you like. Great for bulk changes, great in general.
Not last, not least, but also not as user friendly as the rest and the last in my review here is LDP.exe. Microsoft says it best "Ldp.exe is a Windows 2000 Support Tools utility you can use to perform Lightweight Directory Access Protocol (LDAP) searches against the Active Directory for specific information given search criteria. This also allows administrators to query data that would otherwise not be visible through the Administrative tools included in the product. All data that is returned in LDP queries, however, is subject to security permissions."
With all of these tools you are beginning to get an unfiltered view into the raw LDAP structure that is underlying what most Administrators know as Active Directory. You can use these tools to view the structure and if you have permission, edit the same structure. I'll assume for the rest of the blog that when I say, edit, I mean edit if you have permission.
For one-off changes and editing I tend to like the newest of the bunch the best. Mark and Bryce have done a great job with AD Explorer. It is as GUI as you need, has great capabilities, and extends beyond simple AD Editing. It also has a great utility to back up the entire AD domain for roll-back possibilities.
That's all for now, I hope you enjoy my finds and please comment if you find more that I should know about.
Cheers.
By: Aaron Steele
Posted:
March 31, 2008 at 8:49 PMAs you probably know Office Communication Server 2007 from Microsoft supports and can very easily be seutp for federation with the public IM providers. Yahoo, MSN and AOL are the supported protocols. Microsoft kindly provides the intial setup and it works. For MSN connectivity, you can add any "Live Enabled" email address to your contact list and IM it just as though it was inside your organization. Adding an @AOL.com address or an @yahoo.com address simply allows the same connection.
The catch/configuration comes on the client side, when you as an OCS user want to contact a MSN user that has configured their personal or work email as their "Live enabled" MSN IM id, you must change the way you represent their email address. If the MSN IM email Live Enabled email address is aaron@example.com, you would format it as aaron(example.com)@msn.com. We lately have had some issues with one provider in particluar though. MSN federation has been giving us fits. We continue to get reports from our users that they have intermittent problems, that MSN users report intermittent problems sending IMs to them and that in general the level of frustration is running high.
We have contacted PSS, and through them contact has been made with the MSN team and so far, we have no resolution. Working with MSN we came to suspect our Firewall, we came to suspect our ISP and we came to suspect our hardware. We undertook testing and ruled out the firewall, we can't find a place to lay blame on any of our service providers or our hardware. At this point, we still don't know the cause and don't have an end resolution. Sorry to say it, dear reader, but that is the fact as it sits. We have errors, that lots of other OCS systems have, about errors federation with the MSN server, X many in the past day and so on. Nothing can be done. The product is great and I have to thank Derek Seaman for working with Microsoft PSS on this issue. |
|
|
|
 |
|
|
|
 ConsultantAaron Steele is a consultant for PointBridge. He has over 18 years of experience in the IT industry ranging from telecommunications design work, and work for higher education institutions including Ac... [more]
|
|
|
|
|
|