During our migration project from Lotus Notes to Office 365, we were doing an inventory of mailbox sizes to determine which ones to migrate first.

So our Lotus Notes admins gave us a CSV file with the users and their mailbox size in bytes. The goal was to fetch the mailboxes under 1 GB of size that would be a part of a Pre-Pilot. Could’nt be easier, right?

I imported the file, verified it got parsed correctly and went ahead and looked for the < 1 gb mailboxes. The results I expected were that most of the ~100 mailboxes would be under this limit.

But I got four…

What has happened? I tried to find out how big the total was by adding them all togheter:

Ok… So things are becoming really weird, I have 99 mailboxes in this file, with 4 of them being under 1 gb in size, but the total is 83,6? What has happened?

The answer comes now:

Look at the definition of the Size-property… System.String!!!

Why would PowerShell do that with something that clearly only contains numbers?

Let’s force it to handle them correctly…

That did not work at all… But now we have the explanation! Some of the mailbox sizes in this file are simply to big to be stored as an [int] since it’s 32-bit!

We need to convert this to a 64-bit value, pretty obvious when you think about it, but since PowerShell usually takes care of these things for us, it’s easy to forget…

So how to fix it?

We simply tell PowerShell that Size is of the type [long]. Let’s go back the Where-clause we had in the beginning:

Works perfectly… Let’s do a count:

Now it makes sense!

Conclusion:

PowerShell does an awesome job on creating objects for us, guessing the property types and so on, “it just works” most of the time.

But when working with larger numbers, make sure you aren’t working with strings!