Hi all, I'm going slightly insane with warnings not being supressed in the following statement: for ($i = 0; $i -lt 30; $i++) {$lmb[$i] | New-MoveRequest -TargetDatabase MailboxDB22 -BatchName DB20toDB22 -BadItemLimit 20 -WarningAction:silentlycontinue} Has anyone else using New-MoveRequest noticed if it's not honouring the -WarningAction:silentlycontinue directive? Cheers, Lain

Hi, It happends because the number of bad items are more than 20. You may set a large bad limit for eg.1000 and try againRegards from www.windowsadmin.info | www.blog.windowsadmin.info

Hi Manu, My apologies, perhaps I didn't explain this well enough. The warning isn't being displayed during the mailbox move as you're implying, but as part of the scheduling of the request with New-MoveRequest. Also, from memory what you're referring to is when you either forget the BadItemLimit or set it too low, in which case that comes out as an error and terminates that particular move, not just issuing a warning. Cheers, Lain

The -WarningAction will not supress any warning! It just determines how the cmdlet responds to a warning: if it should stop, if it should continue, etc... Try using the -WarningVariable as well but I think it will still output to the shell... If this doesn't work, you can also try the Out-Null: for ($i = 0; $i -lt 30; $i++) { $lmb[$i] | New-MoveRequest -TargetDatabase MailboxDB22 -BatchName DB20toDB22 -BadItemLimit 20 -WarningAction:silentlycontinue -Warning Variable Err | Out-Null } http://LetsExchange.blogspot.com

Hi Nuno, From my experience, both -WarningAction and -ErrorAction do indeed supress warning and error messages respectively. As a simple test, run a Get-Mailbox on a database with more than 1000 mailboxes without -WarningAction:SilentlyContinue and then with it. Notice how the warning isn't shown with it present? I have numerous operational examples of ErrorAction if you would like those, but it's not really needed - you can test it out yourself. The only thing that makes sense to me is that within New-MoveRequest, the WarningAction is correctly passed in (as shown by (Get-Command New-MoveRequest).Definition but not actually used within the function itself when using the Warning channel. Again, this is the only commandlet I use semi-regularly that doesn't honour the parameter. While this isn't a major issue, I figured I'd still ask if anyone else was experiencing what I'm seeing on both our Exchange servers. Mostly I'm asking out of curiosity, though it would just be a tad more convenient when working from the command line if the initial warning of New-MoveRequest when run with the -BadItemList parameter could be controlled with -WarningAction. Cheers, Lain

Hi Lain, Could you please post the warning message here? And if possible, please run the cmdlet against two or threee test mailboxes with -verbose parameter and post the result here. For example: Get-Mailbox | where {$_.company -eq "test"} | New-MoveRequest -TargetDatabase MailboxDB22 -BadItemLimit 20 -WarningAction:silentlycontinue -verbose Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com. Frank Wang TechNet Community Support

Hi Frank, I'll provide another post after using the -Verbose parameter tonight when I have the opportunity to move more mailboxes, but for now here's a copy of the initial warning New-MoveRequest provides when the -BadItemLimit parameter is used: WARNING: When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox. Cheers, Lain

Hi Frank, As promised, here's one example from a run of 20 queued mailbox moves including the -Verbose parameter. This output is generated immediately from the execution of the command, not as part of the actual move. You'll find the following expansive dump validates this as the warning appears before the job has even been queued (it appears around line 10). Hence why I think the -WarningAction parameter is not being used by the Write-Warning (or equivalent) statement for at least this particular part of the New-MoveRequest function. Naturally, I've either removed or changed account references and so on. Cheers, Lain VERBOSE: [13:12:16.447 GMT] New-MoveRequest : Active Directory session settings for 'New-MoveRequest' are: View Entire Forest: 'False', Default Scope: 'domain.edu.au', Configuration Domain Controller: 'dc01.domain.edu.au', Preferred Global Catalog: 'dc01.domain.edu.au', Preferred Domain Controllers: '{ dc01.domain.edu.au }' VERBOSE: [13:12:16.462 GMT] New-MoveRequest : Runspace context: Executing user: domain.edu.au/University /Administrators/Users/someAdmin, Executing user organization: , Current organization: , RBAC-enabled: Enabled. VERBOSE: [13:12:16.462 GMT] New-MoveRequest : Beginning processing & VERBOSE: [13:12:16.462 GMT] New-MoveRequest : Instantiating handler with index 0 for cmdlet extension agent "Admin Audit Log Agent". WARNING: When an item can't be read from the source database or it can't be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox. VERBOSE: [13:12:16.462 GMT] New-MoveRequest : Searching objects "MailboxDB02" of type "MailboxDatabase" under the root "$null". VERBOSE: [13:12:16.462 GMT] New-MoveRequest : Previous operation run on domain controller 'dc01.domain.edu.au'. VERBOSE: [13:12:16.478 GMT] New-MoveRequest : Current ScopeSet is: { Recipient Read Scope: {{, }}, Recipient Write Scopes: {{, }}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive Recipient Scope(s): {}, Exclusive Configuration Scope(s): {} } VERBOSE: [13:12:16.478 GMT] New-MoveRequest : Searching objects "domain.edu.au/University/Staff/Users/123456" of type "ADUser" under the root "domain.edu.au/University/Staff/Users". VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Previous operation run on domain controller 'dc01.domain.edu.au'. VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Processing object "$null". VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Searching objects "MailboxDB00" of type "MailboxDatabase" under the root "$null". VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Previous operation run on domain controller 'dc01.domain.edu.au'. VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Searching objects "MailboxDB02" of type "MailboxDatabase" under the root "$null". VERBOSE: [13:12:16.494 GMT] New-MoveRequest : Previous operation run on domain controller 'dc01.domain.edu.au'. VERBOSE: [13:12:16.509 GMT] New-MoveRequest : [DEBUG] No RequestJob messages found. VERBOSE: [13:12:16.509 GMT] New-MoveRequest : [DEBUG] MDB 97531e5b-f020-1234-83fa-91a4325cbbd5 found to belong to Site: domain.edu.au/Configuration/Sites/Fremantle VERBOSE: [13:12:16.509 GMT] New-MoveRequest : [DEBUG] MRSClient: attempting to connect to 'exc01.domain.edu.au' VERBOSE: [13:12:16.509 GMT] New-MoveRequest : [DEBUG] MRSClient: connected to 'exc01.domain.edu.au', version 14.1.355.1 caps:07 VERBOSE: [13:12:16.509 GMT] New-MoveRequest : [DEBUG] Loading source mailbox info VERBOSE: [13:12:16.540 GMT] New-MoveRequest : [DEBUG] Source mailbox info: mbxGuid=[removed] mbxName='domain.edu.au/University/Staff/Users/123456 mbxHomeMdbGuid=[removed] mbxSize=181.4 MB (190,229,809 bytes) (deleted=0 B (0 bytes)) mbxItemCount=822 recipientType=UserMailbox UserMailbox ACLableMailboxUser archiveGuid=00000000-0000-0000-0000-000000000000 altMailboxes=(not present) mbxQuota=(unlimited) mbxDumpsterQuota=(unlimited) mbxArchiveQuota=(unlimited) mdbGuid=[removed] mdbName='MailboxDB00' serverVersion=Version 14.1 (Build 355.0) mdbQuota=(unlimited) mdbDumpsterQuota=10 GB (10,737,418,240 bytes) rulesSize=0 serverInfo=Mailbox server 'exc01.domain.edu.au' Version 14.1 (Build 355.0) VERBOSE: [13:12:16.540 GMT] New-MoveRequest : [DEBUG] Loading target mailbox info VERBOSE: [13:12:16.556 GMT] New-MoveRequest : [DEBUG] Target mailbox info: mbxGuid=[removed] mbxName='domain.edu.au/University/Staff/Users/123456 mbxHomeMdbGuid=[removed] mbxSize=0 B (0 bytes) (deleted=0 B (0 bytes)) mbxItemCount=0 recipientType=UserMailbox UserMailbox ACLableMailboxUser archiveGuid=00000000-0000-0000-0000-000000000000 altMailboxes=(not present) mbxQuota=(unlimited) mbxDumpsterQuota=(unlimited) mbxArchiveQuota=(unlimited) mdbGuid=[removed] mdbName='MailboxDB02' serverVersion=Version 14.1 (Build 218.0) mdbQuota=(unlimited) mdbDumpsterQuota=10 GB (10,737,418,240 bytes) rulesSize=0 serverInfo=Mailbox server 'exc01.domain.edu.au' Version 14.1 (Build 218.0) VERBOSE: [13:12:16.556 GMT] New-MoveRequest : Admin Audit Log: Entered Handler:Validate. VERBOSE: [13:12:16.556 GMT] New-MoveRequest : Admin Audit Log: Exited Handler:Validate. VERBOSE: Creating move request "domain.edu.au/University/Staff/Users/123456". VERBOSE: [13:12:16.556 GMT] New-MoveRequest : Resolved current organization: . VERBOSE: [13:12:16.556 GMT] New-MoveRequest : [DEBUG] 10/01/2012 9:12:16 PM [frmpexc01] 'domain.edu.au/University /Administrators/Users/someAdmin' created move request. VERBOSE: [13:12:16.572 GMT] New-MoveRequest : Saving object "RequestGuid (97a33ff2-b9e9-4be3-9d5b-0b8796a3f169), RequestQueue: (47442e9b-f991-4521-83fa-04a8525cbbd5)" of type "TransactionalRequestJob" and state "New". VERBOSE: [13:12:16.572 GMT] New-MoveRequest : [DEBUG] Updating Index/ADUser data for RequestJob 'RequestGuid (97a33ff2-b9e9-4be3-9d5b-0b8796a3f169), RequestQueue: (47442e9b-f991-4521-83fa-04a8525cbbd5)'. VERBOSE: [13:12:16.587 GMT] New-MoveRequest : Previous operation that ran on: 'dc01.domain.edu.au'. VERBOSE: [13:12:16.587 GMT] New-MoveRequest : Reading new object "RequestGuid (97a33ff2-b9e9-4be3-9d5b-0b8796a3f169), RequestQueue: (47442e9b-f991-4521-83fa-04a8525cbbd5)" of type "TransactionalRequestJob". VERBOSE: [13:12:16.603 GMT] New-MoveRequest : Previous operation that ran on: 'dc01.domain.edu.au'. User Name Queued 181.4 MB (190,229,809 ... 0 VERBOSE: [13:12:16.650 GMT] New-MoveRequest : Admin Audit Log: Entered Handler:OnComplete. VERBOSE: [13:12:16.993 GMT] New-MoveRequest : Admin Audit Log: Exited Handler:OnComplete. VERBOSE: [13:12:16.993 GMT] New-MoveRequest : Ending processing &

Hi Lain, Your outputs are same as mine in my test lab. Seems like the warning message is only invoked by the -BadItemLimit. Maybe you have to omit the parameter in your cmdlet at the moment. I'm researching the issue and will update it. By the way, Technet also recommend that you keep the default value 0 and only change the BadItemLimit parameter value if the request fails. New-MoveRequest http://technet.microsoft.com/en-us/library/dd351123.aspxFrank Wang TechNet Community Support

Hi Frank, Thanks for reproducing the issue. Without belabouring the point, we inherited a fair number of "bad" mail items from the migration of the positively antiquated Sun Java Messaging across to Exchange 2010, which in itself had to be done indirectly with Exchange 2007 in the middle (IMAP to Exchange 2007, then 2007 to 2010). We originally tossed around the idea of cancelling on the first bad item when moving content from SJM to Exchange 2007, but we just had too much to move and too little time in which to do it - to the point I had a number of 100+ hour working weeks back-to-back just moving mailboxes. So, while I completely understand the recommendation of leaving BadItemLimit at 0, we're stuck with it until someone has the time and inclination to track down the bad items and resolve the issues. Cheers, Lain