We are trying to move all our mailbox off the primary database in order to reclaim white space. We are nearly finished moving the user mailboxes but I can't work out how I'll move the shared mailboxes. When I try the "Move-Mailbox -Identity -TargetDatabase" cmdlet, I get the message ... "Move-Mailbox : This task does not support recipients of this type. The specified recipient (xyz) is of type SystemMailbox. Please make sure that this recipient matches the required recipient type for this task." Anyone know what I'm doing wrong, or not doing? Thanks

HI OSPhil, Shared mailbox type in Exchange 2007 is account which AD account would be disabled. Can you try by AD account enable and move ? I also need to test it :) Anil

Hi Anil, It's not possible to enable the AD account as I get the following error message when I attempt "Windows cannot enable object because: Unable to update the password. Value provided for the new password does not meet the length, complexity or history requirement of the domain." I think this is because Exchange creates the AD account using a blank password and this is against our set Domain policy which requires a pw of at least 6 characters. Do you have any other ideas? Surely you don't have to allow blank passwords on your domain to move a shared mailbox? Thanks for your initial suggestion. I'm keen to explore all possible solutions.

On Sun, 6 Mar 2011 15:51:13 +0000, OSPhil wrote: >It's not possible to enable the AD account as I get the following error message when I attempt > >"Windows cannot enable object because: Unable to update the password. Value provided for the new password does not meet the length, complexity or history requirement of the domain." > >I think this is because Exchange creates the AD account using a blank password and this is against our set Domain policy which requires a pw of at least 6 characters. Do you have any other ideas? Surely you don't have to allow blank passwords on your domain to move a shared mailbox? No, but your policy is to have a assword for a user account. As long as the account's disabled it can't be used so there's no need for a password. Set the password on the account with ADUC. Then enable the account. Move the mailbox. Disable the account. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, Thanks for your suggestion, but after changing pw, enabling the account (successfully) and retrying the move, I get the exact same error as I originally reported. No change. Before posting here, I tried to change the mailbox type from shared to user, given the error suggests it's the mailbox type that is the problem, but got an error (which I forget) so I decided to just put the issue up here for assistance. Should I go back to that approach now or is there something I'm still overlooking/unaware of here? Thanks again

On Sun, 6 Mar 2011 17:36:38 +0000, OSPhil wrote: > > >Hi Rich, > >Thanks for your suggestion, but after changing pw, enabling the account (successfully) and retrying the move, I get the exact same error as I originally reported. No change. > >Before posting here, I tried to change the mailbox type from shared to user, given the error suggests it's the mailbox type that is the problem, but got an error (which I forget) so I decided to just put the issue up here for assistance. Should I go back to that approach now or is there something I'm still overlooking/unaware of here? I missed this in the original post. The recipient type is "SystemMailbox"? Have a look at that user object with ADSIEDIT or LDP.exe and see what the msExchRecipientTypeDetails value is. It should be "4". If it isn't, use the "set-mailbox <name> -type shared" to make it so. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I've checked that in ADSIEDIT and it is set to "4". Can you think of anything else to try/look at?

On Sun, 6 Mar 2011 19:25:37 +0000, OSPhil wrote: >I've checked that in ADSIEDIT and it is set to "4". > >Can you think of anything else to try/look at? I can think of a couple of things I'd try. 0. Check the objectClass of the user. It shouldn't be "msExchSystemMailbox"! 1. Verify that permission inheritence is allowed on the object. 2. Verify that the user isn't a member of any priviledged groups. 3. Disable the mailbox and then reattach the mailbox to the user, followed by setting the type to "shared". Make note of who should have FMA permission before disabling the mailbox. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Sun, 6 Mar 2011 19:25:37 +0000, OSPhil wrote: >I've checked that in ADSIEDIT and it is set to "4". > >Can you think of anything else to try/look at? I can think of a couple of things I'd try. 0. Check the objectClass of the user. It shouldn't be "msExchSystemMailbox"! 1. Verify that permission inheritence is allowed on the object. 2. Verify that the user isn't a member of any priviledged groups. 3. Disable the mailbox and then reattach the mailbox to the user, followed by setting the type to "shared". Make note of who should have FMA permission before disabling the mailbox. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP 0. It's not. 1. It is. 2. It isn't. 3. Won't be able to check this tonight as my wife is getting annoyed with me checking here and I need to return to her company! ;) Thanks for your continued suggestions.

On Sun, 6 Mar 2011 19:25:37 +0000, OSPhil wrote: >I've checked that in ADSIEDIT and it is set to "4". > >Can you think of anything else to try/look at? I can think of a couple of things I'd try. 0. Check the objectClass of the user. It shouldn't be "msExchSystemMailbox"! 1. Verify that permission inheritence is allowed on the object. 2. Verify that the user isn't a member of any priviledged groups. 3. Disable the mailbox and then reattach the mailbox to the user, followed by setting the type to "shared". Make note of who should have FMA permission before disabling the mailbox. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP Well I was able to attempt the final suggestion (3.) this morning. It made no difference and I received the same error. However while going through the steps, I did notice that the user associated with the shared mailbox was in the 'Microsoft Exchange System Objects' OU. It made sense to consider that as a system object, it may have a knock-on effect of giving it's associated mailbox system-like properties that were then highlighted during the move process. So I moved the user object to the 'Microsoft Exchange Security Groups' OU, then retried the original move cmdlet and it worked! So case solved in that respect. To confirm, I was able to move the shared mailboxes without the need to have the user account enabled. I'd be curious as to whether anyone can explain whether it is the expected default for these users to be created in the 'MESysGroups' OU, or whether this was something that we did incorrectly when they were originally set up? Also is it ok to mark this post as being 'the answer' or should I do differently? I don't use the forums frequently enough to know the correct protocol here. Thanks to all who have assisted me in figuring this out.

On Mon, 7 Mar 2011 13:01:16 +0000, OSPhil wrote: >On Sun, 6 Mar 2011 19:25:37 +0000, OSPhil wrote: >I've checked that in ADSIEDIT and it is set to "4". > >Can you think of anything else to try/look at? I can think of a couple of things I'd try. 0. Check the objectClass of the user. It shouldn't be "msExchSystemMailbox"! 1. Verify that permission inheritence is allowed on the object. 2. Verify that the user isn't a member of any priviledged groups. 3. Disable the mailbox and then reattach the mailbox to the user, followed by setting the type to "shared". Make note of who should have FMA permission before disabling the mailbox. :-) --- Rich Matheisen MCSE+I, Exchange MVP >--- Rich Matheisen MCSE+I, Exchange MVP > >Well I was able to attempt the final suggestion (3.) this morning. It made no difference and I received the same error. However while going through the steps, I did notice that the user associated with the shared mailbox was in the 'Microsoft Exchange System Objects' OU. It made sense to consider that as a system object, it may have a knock-on effect of giving it's associated mailbox system-like properties that were then highlighted during the move process. > >So I moved the user object to the 'Microsoft Exchange Security Groups' OU, then retried the original move cmdlet and it worked! So case solved in that respect. To confirm, I was able to move the shared mailboxes without the need to have the user account enabled. A shared mailbox isn't a system objec or a security group. Move the user object to one of your normal OUs. >I'd be curious as to whether anyone can explain whether it is the expected default for these users to be created in the 'MESysGroups' OU, or whether this was something that we did incorrectly when they were originally set up? When you create a mailbox, why are you putting it into the MESO OU? >Also is it ok to mark this post as being 'the answer' or should I do differently? I don't use the forums frequently enough to know the correct protocol here. You can, but I've never seen an AD User placed into the MSEO OU in any system I've looked at in the last decade. How are those AD users getting into that OU? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich, Thanks for your continued interest. I've not had any formal training in Exchange 2007 and when it came to setting up the shared mailbox, I followed some internet research and completed same via the powershell. Being honest, I did not fully understand what I was doing due to having little experience with the powershell at the time, but when I came out the other side, the shared mailboxes worked and I didn't think any more of it. I don't have any recollection of the specific procedure I used, nor any part which led to the associated user objects being placed in the MESO OU, but it must have been part of the setup I used as all three shared mailboxes had their associated user objects in MESO. As for how the AD users are getting into that OU, perhaps it is due to the fact they are all domain admins? Apologies if the bizarre setup misled you in a manner that is now frustrating to you. I appreciate your input as you got me poking in the right area for me to discover the correct solution. Thanks again

On Wed, 9 Mar 2011 09:48:34 +0000, OSPhil wrote: >I've not had any formal training in Exchange 2007 and when it came to setting up the shared mailbox, I followed some internet research and completed same via the powershell. Being honest, I did not fully understand what I was doing due to having little experience with the powershell at the time, but when I came out the other side, the shared mailboxes worked and I didn't think any more of it. I don't have any recollection of the specific procedure I used, nor any part which led to the associated user objects being placed in the MESO OU, but it must have been part of the setup I used as all three shared mailboxes had their associated user objects in MESO. As for how the AD users are getting into that OU, perhaps it is due to the fact they are all domain admins? No, the fact that they're members of a privileged group shouldn't affect where the AD user accounts are created. But it sure does affect the inheritence of permissions by those mailboxes and the way they act. Try running the Exchange Best Practices Analyzer's permissions test and see if it points anything out. I'd certainly: 1. Move them out of the MESO OU. 2. Remove those users from any privileged groups 3. Remove the adminCount property from the users (or at least set its value to zero). 4. Enable the inheritence of permissions on the users. After you do that, wait a few hours and check the users for the adminCount property. If it has a value greater than zero the user is still a member of a privileged group, so repeat steps 2, 3, and 4 until the admin count remains at zero. >Apologies if the bizarre setup misled you in a manner that is now frustrating to you. I appreciate your input as you got me poking in the right area for me to discover the correct solution. It's not frustrating, it's just somewhat astounding to find things in places they should never be! --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi OhPhil, Happy to see you resolve this now. You must mark as answer Rich last post which guided you to go into right OU (MESO) OU :) Keep Posted in future :) Good Luck ! Anil