none
PowerShell and the mystic 1.2GB number - weird behaviour while setting and comparing quota limits RRS feed

  • Question

  • Hey there,

    I hit a strange behavior and fear I can't see the trees for the forest (aka I am doing something wrong). Also this might be the wrong forum - maybe the general PowerShell forum should be addressed. Anyway, here I go:

    I set mailbox quotas through Powershell and one such command is

    Set-Mailbox NAME -UseDatabaseQuotaDefaults $false -IssueWarningQuota "1,2 GB" -ProhibitSendQuota "1,5 GB"

    OK, first things first: On the command line(!) I can not set quotas to e.g. 1.5GB or "1.5 GB", for my regional settings are German. Using 1.5GB will silently(!) translate to 15 GB! I have to use a comma and quotes: "1,5 GB". Without quotes, 1,5GB, throws an error.

    If I create a script, e.g. in PowerShell ISE, put 1.2GB and 1.5GB (not the German variants!) in variables, enter the Set-Mailbox command in the script using the variables and execute it, it will succeed and the values will be correct!!!

    Querying the action afterwards makes things even more interesting. To make things easier to compare, I try to put things in a table. The PowerShell command ist always

    Get-Mailbox NAME | Where-Object {$PSItem.COMPAREQUOTA -le COMPAREVALUE}

    COMPAREQUOTA gets substituted either by IssueWarningQuota or ProhibitSendQuota and COMPAREVALUE by the value/string/characters in the cells below. RESULT ok means, I will be shown the mailbox NAME; fail means I get no result, aka an empty result, shown.

    COMPAREQUOTA COMPAREVALUE RESULT
    ProhibitSendQuota 1.5GB OK
    ProhibitSendQuota "1,5 GB" OK
    IssueWarningQuota 1.2GB fail
    IssueWarningQuota "1,2 GB" fail
    IssueWarningQuota 1.21GB or "1,21 GB" OK

    Questions in the end

    1. What is so special about 1.2GB? Using e.g. 1.4GB does not show this behaviour. 

    2. Why do I have to use regional setting during Set-Mailbox on the command line, but can use different number formats (German and English) while getting and comparing or in a script?

    Kind regards!

    Carsten

    Sunday, May 26, 2019 1:57 PM

Answers

  • Hi Carsten,

    Thanks for explanation. I've done some tests in my lab. When we use set the value to 1.2/1.3/1.4 GB, the compare results are always empty. 

    According to the documentation, unqualified values are typically treated as bytes, but small values may be rounded up to the nearest kilobyte. For instance, 1.4 GB equals to 1,503,238,553.6 bytes, but the value will be rounded up to 1,468,007 KB. Thus the bytes value is always a bit larger than GB value. When we compare with the bytes value, the mailbox will show in the result. 

    However, when the value is set to 1.5GB which exactly equals to 1,610,612,736 bytes, we can see the mailbox in the compare result.

    Regards, 

    Dawn Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to shareexplore and talk to experts about Microsoft Teams.

    Thursday, May 30, 2019 6:02 AM
    Moderator

All replies

  • Hi Carsten,

    1. I can set the value of IssueWarningQuota to any value less than ProhibitSendQuota in PowerShell. Can you see any error message when you run the command to set IssueWarningQuota to 1.2 GB? Is there any relevant error in Event Viewer?

    2. When I do a test in my lab in which the server location is US, the 1,5 GB is translated to 15 GB. Thus, I assume the data format has to correspond with the data format of region setting in the server, when you input a value using Set-Mailbox cmdlet. To get the most qualified pool of respondents about the data format issue, I'd recommend you to ask the question in PowerShell forum.

    Regards, 

    Dawn Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to shareexplore and talk to experts about Microsoft Teams.

    Monday, May 27, 2019 8:17 AM
    Moderator
  • Hi Dawn,

    thankx for answering. Regarding your Points:

    1. I can also set the value of IssueWarningQuota to any value less or equal ProhibitSendQuota. I don't get any error from the cmdlet or in Event Viewer. ONLY the value of 1.2GB, or to say in in German ;-) "1,2 GB", leads to the comparison problem.

    2. Yes, I also think the PowerShell Forum ist the way to go.

    Regards,

    Carsten 

    Monday, May 27, 2019 9:09 AM
  • Hi Carsten,

    Thanks for explanation. I've done some tests in my lab. When we use set the value to 1.2/1.3/1.4 GB, the compare results are always empty. 

    According to the documentation, unqualified values are typically treated as bytes, but small values may be rounded up to the nearest kilobyte. For instance, 1.4 GB equals to 1,503,238,553.6 bytes, but the value will be rounded up to 1,468,007 KB. Thus the bytes value is always a bit larger than GB value. When we compare with the bytes value, the mailbox will show in the result. 

    However, when the value is set to 1.5GB which exactly equals to 1,610,612,736 bytes, we can see the mailbox in the compare result.

    Regards, 

    Dawn Zhou


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to shareexplore and talk to experts about Microsoft Teams.

    Thursday, May 30, 2019 6:02 AM
    Moderator
  • Hi Dawn,

    I marked your last replay the answer. Thank you for your effort!

    One last comment: I think the PowerShell Team should investigate, because it's really a weird or at least better to explain thing, for:

    (1) 1.2GB, "!,2 GB", etc. are not unqualified nor small byte values, so (a) they should not be rounded and (b) should be comparable to themself(!)

    (2) at my place I can use "1,21 GB" or "1,4 GB" and the comparison will be successfull

    Kind regards and thanx again

    Carsten

    Friday, May 31, 2019 1:55 PM