Get-MailboxStatistics | group MailboxDatabase | format-table count

This is a very simple command that just outputs the count (number) of mailboxes you have on a given exchange mailbox server.  Of course, if you have more than one server you’ll need to specificy that inside the command.  Since I only have one, it’s pretty simple.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Let’s say you’re an exchange administrator and you use EAS (Exchange Active Sync) to plug smart phones into your Exchange environment.  You’re probably one of the many out there who do this…I do it in my environment.

Then you stumble across a handy powershell script that will allow you to query your environment for mobile phones that have synched on user accounts and report back the last successful synch as well as any phone details that are reported.  I found this one somewhere (can’t remember):

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "8*"}

foreach ($m in $mailboxes)
{
$devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

You get a nice little list of stuff right?  This should be every single EAS enabled account that has a phone synching with Exchange right?  Wrong. It absolutely is NOT an accurate list of phones that have synched with your Exchange server.

When I executed that powershell scriptlet above on my system it reported back quite a few phones…but my phone, a HTC Evo, was not on the list.  In fact, my account wasn’t reported on the list.  This despite my device synching just fine every 15 minutes.  The integrity of this ‘report’ has been challenged.  So what’s the deal?

Workaround Solution

A quick investigatory glancing at google brings little results…However, I did notice when using the EMC to highlight my account and going to ‘Manage mobile device” I was in for a suprise….because that link wasn’t there on my account.  That’s right, “manage mobile device” is missing on my account.  This despite having Active Synch enabled under the ‘mailbox features’ tab on my account and despite having my device pair up with Exchange in 15 minute intervals.

Searching google for this problem yeilds much better results.  It seems that a flag embedded for a value in Active Directory doesn’t toggle correctly OR isn’t added into AD at all (perhaps bad replication).  Either way, it means you’ll be whipping out trusty adsiedit.msc (per the forum thread linked to above).  The setting that needs toggled is “msExchMobileMailboxFlags” which should be set to 1.  After setting this, you’ll be able to manage the mobile device AND your synch will be picked up by the powershell report above.

The Real Crux

The real crux of the matter is that this toggle shouldn’t have to be set at all and regardless if it is set or not, powershell should be able to report if a device is synching with Exchange.  There is a reason why RIM is #1 when it comes to businesses and smartphones…it’s because you can have 100% accountability for what is on your network at any given time.  With Exchange 2007 and above, it is unfortunately, much like a ring toss at a circus…sometimes you get a ring on that bottle and win a stuffed giraffe but other times you’re going home without plush pals.

Microsoft has a problem here because you can’t trust your own powershell queries.  If it doesn’t work for this individual area (phones, EAS) then what else doesn’t work?  Do we call into question the entire integrity of all powershell commands and commandlets?  What do you think?  I know this workaround is pretty silly on a huge environment with multiple user containers in AD or even mutlipe forests.  Is the workaround something that is tolerable or should Microsoft do more to fix this broken part of their product?

Related posts:

1. ActiveSync Device Report Brian Desmond’s blog has an excellent tip on how to...
2. Microsoft Please, Smarter Not Harder Join the forum discussion on this post My grandfather always...

Related posts brought to you by Yet Another Related Posts Plugin.

A global group cannot have a universal group as its member

So what to do?  How does one convert this group to a universal one?  The problem doesn’t lie with the group  itself but with the membership of the groups.  In order to convert one, you have to convert them all.

The EXPTA blog has an excellent post regarding what is going on with solutions to boot:

As you may know, Exchange Server 2007 and Exchange Server 2010 force you to create all new distribution groups as universal distribution groups.
The reason for this is that Exchange 2007/2010 requires a local Global Catalog (GC) server in the Active Directory site where Exchange resides to query for group expansion. A GC can expand domain local, global, and universal groups. However, domain local groups (and sometimes global groups) can only be expanded within the domain local scope. If the GC is a member of the companyabc.com domain, it will be unable to expand a domain local group in the sales.companyabc.com subdomain.

I’m going to be posting how they solved their problem for posterity but you can head over to the EXPTA blog for the full post which contains much more meat than this post will.

To solve the problem, query the groups and look at how many you have that are global.  Just open up a command window on a domain administrator account and remember that this command may take a while on a large enterprise:

dsquery group -limit 0 | dsget group -samid -scope -secgrp > Groups.txt

Next run the command to convert the global groups to universal.  There are no adverse problems that will result from this…the conversion doesn’t mess with permissions.

dsquery group -limit 0 | dsmod group -c -q -scope u

You WILL have to run this 2nd command many, many times.  See, each time it cycles through the groups it finds the top level one it has not converted and converts it to universal…there may be 3 more subgroups that need converted but it won’t convert them until the parent is a universal.

For more explanation, see the EXPTA blog link above and hopefully this helps someone out!

Related posts:

1. List Delegates in Exchange 2007 Join the forum discussion on this post The Problem of...
2. Moving Mailboxes from Exchange 2003 to Exchange 2007 During a migration from Exchange 2003 to Exchange 2007 many...
3. User Not Appearing in GAL 2007 Fix Join the forum discussion on this post I had a...

Related posts brought to you by Yet Another Related Posts Plugin.

The Problem of Ghost Delegates

There is a problem with Microsoft Exchange 2003 and delegates.  When users are deleted, their delegate or send on behalf attributes are not deleted with them.

This problem has been around since Exchange 5.5 and possibly before and it’s REALLY annoying.  Microsoft has a hotfix available for Exchange 2003…but the problem is, you have to know WHICH mailboxes the fix needs to be run on.  Top that off with my environment actually being Exchange 2007 and NOT 2003 and one might discover an even larger problem.

Let’s backtrack and define the problem with a little story:

Say you work for Acme Corp which has 1500 employees in a single forest environment running Exchange 2007.  John Smith, an employee of 10 years at your corporation has left for greener pastures over at Emca Corp.  John was a delegate with send rights on Frank Doe’s mailbox as he was Frank Doe executive assistant for almost all of those years.

When HR notified your Active Directory administrator that John Smith had left, they promptly disabled and later deleted the user…this may have happened while you were still using Exchange 2003.

Now you have a problem…John Smith has left the company and was a delegate on Frank Doe’s mailbox.  When someone sends an invitation to a meeting with Frank Doe or mail to a group that Frank Doe is a part of…they may get an Non Delivery Notice (NDR) similar to the following:

Smith, John
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

_____

Sent by Microsoft Exchange Server 2007

This glitch is EXCELLENT for annoying users everywhere!  It’s also a potential problem as someone could mass email Frank Doe and potential generate a NDR in addition to each email they send.  If they were to identify a few more people who may have had this problem, the possibility of having twice the amount of email generated and thus, twice the amount of email traffic, is something that large corporations may not want to have in their existing Exchange environments.

Microsoft realized that they had a problem on their hands and released a fix that you apply to mailboxes that suffer from the ‘ghost delegate’ “feature”.  Great right?  This fix is of course for Exchange 2003…so if you’re using that, you’re set.  You still will need to know a major detail before proceeding though:

1. How many mailboxes have this problem? (usual response)

Therein lies the major problem.  How do you identify which mailboxes have old ghost delegate cruft still floating around generating NDR’s all over the place?  Especially in smaller environments where EVERYONE was a delegate of everyone else?

It’s impossible.

You can try to identify which mailbox has the problem but you would have to use the process of elimination…not a very time saving process and definitely not something I want to do (imagine visiting 50+ users!).  Instead,  I elected to identify all current users with delegates on their mailbox because chances are that the ghost delegate was once a delegate of these identified users.  I plan on cross referencing these users with a distribution list that is generating the NDR to properly identify the problem.  So, onward with how to identify the potential problem with a powershell query.

Identifying Problem Mailboxes with Powershell

Search the web, I’ve found many different ‘solutions’ to this problem with none of them getting things exactly how I needed them to be.  Some of the solutions would run a query and return information that was valuable…but not valuable enough.  Other queries should have worked but didn’t.

I’m by no means a powershell expert so I’m absolutely sure this little scriptlet can be improved.  It does the job though by returning anyone who has a delegate and listing who each delegate is.  So without further fanfare, the powershell command:

Get-Mailbox -resultsize unlimited | Where {$_.GrantSendOnBehalfTo -ne $null} | select Name, @{Name='GrantSendOnBehalfTo';Expression={[string]::join(";", ($_.GrantSendOnBehalfTo))}} | Export-CSV C:\SendOnBehalfTo.csv -noTypeInformation

Let’s break this command down.  The first portion Get-Mailbox -resultsize unlimited retrieves all user mailboxes and doesn’t limit to 1000 as is default with Exchange 2007.  We pipe this command into the next one with the ‘|’ symbol.  Here we use a conditional Where and select the attribute GrantSendOnBehalfTo returning only mailboxes from the first part of the command where said attribute is NOT null or empty.

Next, out of these mailboxes that don’t have the GrantSendOnBehalfTo attribute as empty, we select the Name of the user.  Now we should be able to stop here, however, we’re working with a string attribute here and returning Name will return a Multivalued property instead of the proper DN or user name we’re looking for (something like this Microsoft.Exchange.Data.MultiValuedProperty`1[Microsoft.Exchange.Data.Directory.ADObjectId] ).  To get what we need, we have to join the Multivalued property (string) with the results from the first half of the query.  To do this we create a commandlet and use the join command to bind the first part of our command to the multivalued property and translate that property into something readable for us.

It’s in the string conversion section that most people get frustrated with.  I know I got frustrated with it and used a portion of a commandlet for allowing a user or group to only accept messages from certain mailboxes…I just adapted that string conversion and join for my own purposes.  Like I said, I’m not extremely fluent in the ways of the powershell script…I just know that adapting it worked.

Identifying the Problem Mailboxes with Active Directory Queries

Of course, after spending 6-8 hours constructing my query in powershell I found a simple little tool from Joeware.net called “ADFind” that allowed me to execute a simple AD query and output all of the same information into a much more readable format than my powershell command.  If you’d like to do the same thing, head over to the ADFind page, enter your email and download the tool.  Extract it to your desktop and then open a command prompt and change directory to your desktop.  Next, enter a proper AD query with the adfind.exe prepended:

AdFind.exe -default -f "&(homeMDB=*)(publicdelegates=*))" publicdelegates > C:\delegates.txt

The output from Joe’s tool is MUCH nicer than what I was able to accomplish using powershell.  I’m sure someone will be able to take what I did with powershell and improve on it…but when there are handy tools like joeware provides, what need is there?

Implementing the Microsoft Fix

The ‘official’ fix from Microsoft is to install a hotfix if you’re running Exchange 2003.  Supposedly, Exchange 2007 doesn’t suffer from this problem…but there is a caveat there.  If, like me, you’ve upgraded from an Exchange 2003 environment that suffered from this problem…you migrate the problems with it!  So, I have an Exchange 2007 environment suffering from ghost delegates and NDR’s.

How to remedy this?  There are 3 directions provided.  The first from Microsoft is to go inside the tools >> options menu in Outlook and delete the delegate.  The problem with ghost delegates is that they aren’t there…which renders this fix completely useless.  The second solution is to launch Outlook with the /cleanrules switch.  The third solution out there is to use the MFCMapi Editor on the user mailbox that has the problem, find the hidden bits, and delete them.  The problem with this solution is most people AREN’T comfortable with editing the profile inside a snap-in…it’s much like using ADSIEdit to edit AD manually and can be overwhelming.

Examining the 3 options, it’s obvious that /cleanrules switch is probably the easiest to implement.  The problem is that it will delete ALL rules from the mailbox and if you have users who have been around for quite some time it means tons of rules.  The other problem is that it has to be run manually on EACH mailbox.  This of course is bad if you have an elaborate delegate system.

When we identified who has delegates with our queries above, we most likely found a culprit for who is having the problem and generating the NDR.  For me it was rather easy because I cross referenced my list of those with delegates with a distribution list.  When one of the unit secretaries sent email to this distribution group, it would also generate the dreaded NDR.  This means that a member of the distribution group has a ghost delegate.  Cross referencing gave me a list of 6 people to run the /cleanrules switch on versus the over 50 delegate mailboxes from the queries above…a much smaller number to visit.

I hope my confusing process can help someone out there and please improve on anything you see here…as I said, I’m by no means an expert…I just like to document my learning process to help others and also to remind myself of the fixes I find   Thanks for reading!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Thanks for reading!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Thanks to powershell, I now think in pipes…while I’ve always done this with Linux, I’ve never had to do so with Windows.  It’s almost like wearing two caps at the same time.  Nonetheless, I was able to figure out how to do this after 3 or 4 attempts and then output it to a file so I could see members of the security group and I did so without the power of powershell (ba-dum-ching!)

I used dsquery and piped the command using dsget to grab the information I needed and then output that into a text file onto the desktop.  Important to note that you should open the command window using ‘run as’.  So in XP, browse to Start >> Programs >> Accessories and then right click ‘command prompt’ and ‘run as’ with elevated privileges.  You’ll need to be able to view the group you’re querying.  I used my own user since I’m a domain admin…you get the idea.  Once you have the command prompt, cd to Desktop so the text file will be easy to find.  Then initiate the following command:

dsquery group -name GroupName |dsget group -members |dsget user -display >memberlist.txt

Substitute for GroupName and put in the group you’re looking for.  Hopefully this helps out.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I had a problem since our migration from Exchange 2003.  The problem was a handful of users were not appearing on our Global Address List.

Tracking down what was going on has taken me quite a long time despite Microsoft KB articles published on the matter.  The solution posted by Microsoft in this instance just didn’t work for me.  I ran that powershell command until I was blue in the face and it returned zero results.  To find out how this happened and why they’re not displaying, I had to dig around for many weeks and create a custom powershell scriptblock until I FINALLY found the answer.  Hopefully, passing on this info here will save readers time and effort in their search for resolution of the same thing.

Why Is It Happening?

The reason this is happening is that when you first move from Exchange 2003 to Exchange 2007 or 2010, you have a “Default Policy” in Email Address Policy that should be automatically created (expecially if you run in tandem like I did).  This policy is carried over from Exchange 2003.  Microsoft changed the way 2007 filters work…they no longer use LDAP as they did with Exchange 2003, they now use OPATH.  For a more detailed explanation on this, see this blog post.  This default policy can be found in the Exchange Management Console >> Organization Configuration >> Hub Transport.  The default policy will place the ‘user alias’ in front of the domain that you have set for your receive connector.  When you first apply the policy, it appears like this:

default policy

Where can you view the screen pictured?  You can click edit on the default policy found in the location above and press next a couple of times and then cancel out  (you don’t want to apply the policy another time do you?).

This information lets us know that the default policy sets up our domain (edited to show domain.com in the picture) with the user network name, aka alias, so that users can immediately send and receive based on login names.  Often times, if you are in a small organization, users may login with firstname.lastname or firstinitial.lastname and this may be their email address as well.  In this case, you wouldn’t implement a secondary email address policy like I had to do.

Our organization wanted to receive email with firstname.lastname.  They’ve implemented a network name (aka alias) policy of first two initials of first and last name followed by last three of employee number.  So if my name were John Smith and my employee number were 12345, the network name would become josm345.  This is great for not having repeat names on our network but it’s bad for emailing people.  Enter my secondary email policy.

secondary policy

The secondary email address policy I created after we switched off Exchange 2003 set up the domain to be able to send and receive with firstname.lastname@domain.com.  I then applied this secondary policy and the SMTP address it created as the primary SMTP address for all users and gave this policy a higher priority over the default policy noted above.  You can see from the picture the policy takes firstname and lastname in front of the domain.

I also had to update all address lists as shown in this helpful blog post at MXExchangeteam.com.  After this, I updated the offline address book by going to Organization Configuration >> Mailbox >> Offline Address Book >> Right-click Update.  If you need to create a new global address list, you can’t do it from the EMC, you have to do it via Exchange Management Shell.

It’s a long process, but once you know that you have TWO email address policies that are applied, it makes sense that if a user doesn’t have both of the criteria to match these policies they will not appear on the Global Address List nor the Offline Address Book.  So now we have found out who this has happened to and then we’ll know why users are not showing up in these lists.  We also need to know what we need to do in order to fix it.

Finding Users Without Both SMTP Addresses

If we find users without both SMTP Addresses present on their mailbox, we will find the users who are NOT appearing in our Global Address List.  These users either didn’t have both email address policies applied to them or they had one SMTP address deleted.  Either way, if both policies (and thus both SMTP addresses) were not applied to them they will not be included.  You can fix this by adding in the SMTP address that is lacking making sure to appropriately set the one you want to be default.

I tried to use Microsoft’s KB article to find the users without both addresses but the query they wanted me to run via Exchange Management Shell returned nothing back for me.  I looked up what the query was doing and rewrote it how I thought it should be written.  Here’s the finished product and I’ll go through what it’s doing below:

Get-Mailbox -ResultSize Unlimited |Select-Object DisplayName,PrimarySmtpAddress, @{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | export-csv c:\export.csv –NoTypeInformation

First, with ‘Get-Mailbox -ResultSize Unlimited’ we are getting ALL mailboxes in the enterprise.  We’re piping the results using the ‘|’ and then selecting an object based on criteria.  The object criteria we are selecting:  DisplayName so we can tell who the person is, Primary SMTP address and then we’re creating something called a scriptblock with the third ‘Select-Object’ criteria…I’ve taken it out of the command above to help explain it below:

@{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_.PrefixString -ceq “smtp”} | ForEach-Object {$_.SmtpAddress}}} | export-csv c:\export.csv –NoTypeInformation

This command grabs the email address and matches it to the DisplayName we selected previously.  It then searches through each Object and ‘Where-Object’ matches the string “smtp” it displays that information.  Notice it is in lowercase.  The primary SMTP address are stored in AD as capital letters and the secondary SMTP address (or third or fourth, etc) are stored in lower case…so we’re matching ANY other SMTP address (lowercase) that appears for DisplayName.  The results should display similar to the following:

DisplayName    ServerName    PrimarySmtpAddress                EmailAddresses
Nologist, Tek  ExchServer    tekn.nologist@teknologist.net     teno321@teknologist.net

The last portion of the code, ‘export-csv c:\export.csv‘, exports the report to the C: drive as a CSV so we can manipulate it in Excel.  The -NoTypeInformation removes the type information line from the top of our results…mainly because it’s not needed.

Using this query to find the users that are not appearing on your GAL is now as easy as finding blank entries in a CSV   Scan that CSV and where an SMTP address cell is missing (primary as noted in ‘PrimarySmtpAddrss’ or secondary as noted under ‘EmailAddresses’) you can note the DisplayName as a user who is not appearing in the GAL.

After you’re done with the list, you will need to add in the missing SMTP information on each of the users that you noted.  If you’re wondering WHERE to add it in, open the Exchange Management Console >>Recipient Configuration >> Mailbox >> Right-click user >> Properties >> Email Addresses Tab.  From there, you should only see one SMTP address…if you have two policies, you’ll need to add in another SMTP address that matches said policy.  As you can see displayed in the picture, some of my users had only my secondary policy applied.  So when I went to the Email Addresses Tab, some users appeared to only have firstname.lastname@domain.com. I needed them to also have alias@domain.com to match the default policy I carried over from 2003.  To do this, just click the “Add” button and create another SMTP address that matches the user alias@domain.com.  Make sure the checkbox at the bottom is checked so that any lists containing this user are updated.

When I first discovered the solution to this, I thought “Why do I need that default policy after I’ve powered down my Exchange 2003 server?”  Then it hit me!  Users probably still receive mail sent to their alias!  Some of the employees have been here for 30+ years and their alias is still a first initial and last name…who’s to say they don’t still give that out as their email address?  So I had to keep this policy in play whether I wanted to or not.

After you have found all the users that needed another SMTP server added to their Email Addresses area, you’ll need to go back and update the Offline Address Book again (shown above when I spoke about address lists).  The change should be instantaneous for all your OWA users but Outlook users may have to wait for a day before they appear depending on how you have Outlook 2007 setup.  If you’d like your Outlook users to immediately have the change, click on the “Send/Receive” arrow and choose “Download address Book”.  Select the appropriate address book and click “Ok”  Allow it to update and then check to make sure the users that did NOT appear before are actually appearing now.  Congratulations!  You’ve fixed the problem!

I hope that this post does a good job explaining WHY this occurs and how you can find those users and how you can get them to appear in the GAL and OAB again.

Related posts:

1. AllOutlookUsers Distribution List Join the forum discussion on this post One of the...
2. Moving Mailboxes from Exchange 2003 to Exchange 2007 During a migration from Exchange 2003 to Exchange 2007 many...

Related posts brought to you by Yet Another Related Posts Plugin.

Exchange 2007

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "8*"}

foreach ($m in $mailboxes)
{
 $devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

Exchange 2010

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "14*"}

foreach ($m in $mailboxes)
{
 $devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

To use the above info, copy the code into a text file on one of your exchange servers and rename that file with the .ps1 extension.  Next, open up the Exhcange Management Shell and use the ‘cd’ command to change directories until you are in the directory where the .ps1 file is located.  Type ./Filename.ps1 and hit enter to run the script.  The outputted CSV file will be located in the same directory that the file was run from.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

My grandfather always says to work “smarter and not harder” which is 1930′s speak for be more efficient.

Why couldn’t Microsoft have listened to him (and all the other grandpa’s of the world who say the same aphorism)?

I had a user come in the other day with a Windows Mobile HTC Touch Pro 2.  They wanted to hook up to EAS and have all the whiz bang features that my Palm Pre and all the whiz bang features that iPhones are able to have…synchronizing calendar, contacts, and email.  This user is by no means very technical.  They need a way to plug in their email address and server name and have it just work…much in the way that it does for the Palm Pre and iPhone.

The user dropped off the phone to me to handle this for them of course so I entered in all the information and went to connect it.  Promptly, I received the following message:

“your exchange server requires a personal certificate for authorization”

I anticipate this for some phones…on some phones you have to copy across a root certificate in order to have them connect to a SSL enabled CAS from the internet.  This would be my first phone that I’ve run across that didn’t automatically import the certificate.  Now, let me begin by saying this is probably one of the dumbest things I’ve ever heard of before (not automatically importing the certificate) because if you’re connecting to the exchange server and authenticating…you should trust whatever certificate is setup by your administrator automatically.  Locally here on our PC’s in the enterprise, we’ve automatically trusted the certificate from servers we can authenticate with passwords to.

As an example, if Microsoft treated their Domain Controllers in an AD Forest the same way…we’d be getting pop-ups anytime I regenerated a certificate on a DC.  We don’t get those because if a computer is authenticated and the server changes, we don’t want our users getting popups they can’t explain or understand.  We used group policy to silently negotiate the certificate exchange in the background.  We did the same for OWA when it is accessed internally.

But a smart phone running Windows Mobile?  Heck NO!  You have to manually copy the certificate over and import it manually…you’re not given the opportunity to authenticate and import automatically.  Nothing takes place in the background…even if you are ON THE DOMAIN.  The behavior gives you no other alternative.

I thought this would be fine…but it’s not.  There isn’t a way for me to get access to the filesystem of the phone.  I plug it in via USB.  It can’t install it because it can’t find drivers.  I use the software included with the phone and it wants to synchronize locally with Outlook…but the user that is using this phone DOESN’T HAVE OUTLOOK nor do they have their own PC, so why would they want to install software just to be able to get files onto their phone?  Why would I?

In this instance, this phone is locked down…which is fine in a corporate environment.  But this is a personal phone and there is no corporate Windows Mobile plan we have here.  I need it to be as easy as an iPhone.  I need it to be as easy as my Palm Pre.  I need to type in the information and have it connect and start working immediately.  It doesn’t.  Microsoft needs to work smarter and not harder on this.

I wasted 2 hours yesterday trying to get a certificate copied over to the device and I still can’t do it.  I pretty much gave up in frustration and figured I’d file an issue and see what someone can tell me…there comes a point though where security and usability collide in an awesome display of stupidity…and I think this is the case here.

I’m sure everyone is saying “You’re a dummy then!  It’s easy, you just perform action X and they Y and it works!”  and to that I ask that you leave a comment on how you get it working…remember, I can’t copy files to this device…it won’t let me.  So tell me how to get it done without copying files to the device or how to hack the device so I can copy files to it and I’ll agree with you by saying “yes, I am a dummy”.  Documentation on this problem and solution are non-existent…google and live were not my friends on this topic.  So please tell me how wrong I am…I want to be proved wrong and fix this.

In the meantime, please Microsoft, work smarter and NOT harder.  Making things this difficult to do simple things is dumb.  My boss doesn’t care about all the technical details.  She just knows that she took her iPhone in and I had it up and running in about 10 minutes.  And now she knows that one of her directors asked for the same functionality in a Windows Mobile phone and 2 hours later I told him I couldn’t get it to work.  Here it is 2 days later and I still can’t get it to work.  Making it so competitors systems work better on your own product is comparable to shooting yourself in the foot with a canon.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

When migrating from Exchange 2003 to Exchange 2007, I had problems with disk space on one of our network drives.  For the life of me, I couldn’t figure out what the problem was until we had about 100MB left.  Then I realized that every single mailbox move was being logged!  Try running a script that moves hundreds over at a time and then think of the log files!

I ran across a blog post that details just this and what to do about it.  Hopefully you won’t end up like me finding out after the fact!

http://www.telnetport25.com/component/content/article/11-exchmig/320-exchange-2007-tracking-and-analysing-large-mailbox-move-reports-using-the-exchangemovemailboxtaskviewer-tool.html

Related posts:

1. Moving Mailboxes from Exchange 2003 to Exchange 2007 During a migration from Exchange 2003 to Exchange 2007 many...

Related posts brought to you by Yet Another Related Posts Plugin.