We have a no-reply account sending via an IIS SMTP relay for scanners and such. We don't need to store the sent items at all, and now this gives us another headache to worry about, retention/quotas!
The ability to control this should have been included with the initial implementation! Just because some people want to store sent items, doesn't mean everyone does!
Regards to archiving status for existing objects, once you have done an Enable-RemoteMailbox on your existing objects, you need to retrieve the Archive name and GUID from Exchange online, and manually populate them against the on premise objects, for ECP to display the correct archiving status.
Fairly easy with powershell.
Whether or not it is different when archiving is/isn't enabled, I couldn't tell you without more testing.
Anyone any input on getting the archiving status in sync for existing shared mailboxes when enabling-remotemailbox?
Feels like another half baked solution from Microsoft.
If we have existing AD user objects associated/synced to shared mailboxes in cloud, and those cloud mailboxes have archiving enabled, how do we enable archiving on the remote mailbox entry on premise to match?
When doing "Enable-RemoteMailbox" with a "-Shared" switch, you cannot also specify "-Archive".
As such, when the mailbox then appears in the on premise ECP as a shared mailbox, it says archiving is not enabled. This is obviously not the case as the mailbox in cloud does have it enabled.
If I look at the available switches for "Set-RemoteMailbox", there is not one called "-Archive". There is however, "-ArchiveGuid" and -"ArchiveName".
Are we supposed to enable archiving through the on premise ECP GUI option, or are we supposed to retrieve the actual archive GUID from exchange online, and then populate the on premise object using set-remotemailbox -archiveguid?
Deleting via powershell works though :S
Can we also correctly create remote equipment and room mailboxes now, using the -equipment and -room switches, and will they show up under the appropriate tabs in ECP?
Just tried this, and used powershell to create a new remote mailbox of typed shared.
When attempting to delete the mailbox through ECP however, I get a message that states:
"Error, Remote Test isn't a mailbox user."
Anyone else see the same issue when trying to delete a remote shared mailbox through ECP?
This is great news! Just need to wait for it to appear on WSUS so I can get it installed.
Does the AD schema update occur during the installation of the CU, or does it need to be done manually?
Do you know if it also adds GUI options to complete these tasks, or is it powershell only?
I have had a senior engineer advise me that there may be a feature enhancement in the pipeline to work around this. No solid confirmation nor ETA, but I am engaged with them to try and find out. Otherwise, managing remote shared mailboxes is still a bloody nightmare!
One issue I found with the below of editing those attributes, is that you can't then delete the remote shared mailbox from within ECP.
There really needs to be a GUI option added that can create an appropriate on premise object that is a remote shared mailbox, that doesn't require admins to fudge with attributes manually.
You can create a remote room mailbox? Any articles on that, as I didn't think it was possible!
Well, year an a half later and this still isn't possible. My options are add the remote shared mailbox to Exchange on premise as a contact, or as a remote mailbox.
Having them mixed in with normal mailboxes is a nightmare....there is a shared mailbox section for a reason.
Hopefully this gets implemented soon!
I would not expect Microsoft to pass a case to a server team, or on prem Exchange team for example, but at least within the teams that they have 365 services.
For example, if we have login issues with Outlook specifically, they have a Outlook/Office team, and an identity team, either of which I can open a case with.
If I open a case with one, they complete some investigation and say it needs to be looked at by the other, it's frustrating to then have to open another case and go through all the same initial rigamarole that has already been completed by the first team.
Appreciate they have different support methodologies and such, but would like to see them at least use the same support system at the backend to allow moving of cases like this between teams (especially if it requires some collaboration or back and forth between teams).
28 votes0 comments · Office 365 Security & Compliance » Advanced Security Management · Flag idea as inappropriate… · Admin →
I have had multiple battles trying to get support to give this some traction and raise internally. We primarily want this to appear in OWA and the portal, but have been told it is a one time sync. Apparently, they want users to be responsible for this and upload via the portal directly as it has higher quality limits than the on premise attribute, but I have explained that it is an admin nightmare to manage via powershell, especially if you want the on premise and cloud objects to have the same picture (the whole frickin point of AD sync!!!). CodeTwo have recently released this free tool, which may help, but is not a solution to the problem!
I raised this query back in 2015, and decided to try again last month. They are still saying the same thing, and are now suggestion we pay(?) for premier support, and raise it as a suggestion. The only other thing they have told me, is to post more feedback on this site. This is crazy, and isn't going to make a difference. I don't understand why it is designed with this artificial limitation. What's worse, it allows you to sync once, but then never again!
I just got off a call with a support rep who told me exactly the same thing. We are going to deploy a script to generate user profile images for our user profiles on premise (Such as when logging into a server or PC), and are going to use the thumbnailPhoto attribute. Since this is already being synced, and shows up in client apps, I can't see any problem with it being used by all other services!
I feel like this is something really simple to implement, as surely all the GUI does is run powershell commands?
It would save lots of time as well, as we wouldn't have to complete an additional step with powershell to disable automapping!