|
Thanks Ants posted:Are all these people sat behind the same firewall? Yes. Everyone in a single location. Affects maybe 9/70. We've gone though 2 different firewalls, proxy, no proxy, doesn't seem to make a difference.
|
# ? Jul 11, 2017 18:28 |
|
|
# ? May 2, 2024 21:41 |
|
Oscar Wilde Bunch posted:Yes. Everyone in a single location. Affects maybe 9/70. When you create a new profile does the problem happen immediately or does it take some time before it stops working? When someone is in this state of delayed inbound mail, what does the connection status window for Outlook show? Are all of the connections established or is something stuck connecting? Is there anything in common with the people that are having issues as opposed to the people who aren't? I'd take a look at GPOs, wireless access points, network path to the Exchange server, UPN/SIP names, AD object location, delegate/delegate of someone, public folder favorites, pst files on network drives, full mailbox accesses, and Exchange resource accesses.
|
# ? Jul 11, 2017 19:18 |
|
Will Styles posted:When you create a new profile does the problem happen immediately or does it take some time before it stops working? When you create a new profile it does seem to give a little bit before it stops working right, but that time period can be like 30 minutes. The folder shows Up to Date, Connected to: Microsoft Exchange. I can't think of any GPO's that would intersect. WAPs don't come into play, network path is pretty uncomplicated. Object location is that same as everyone else, main complainer is neither a delegate of or to someone else. We don't have public folders anymore, no pst files. We have people affected that were part of the original O365 migration, and some that are only a few months old.
|
# ? Jul 11, 2017 19:29 |
|
Have you let this run? https://support.office.com/en-gb/ar...&rs=en-GB&ad=GB
|
# ? Jul 11, 2017 19:45 |
|
Thanks Ants posted:Have you let this run? Yes, that, and then OffCAT results were the first things that they did when I opened the case.
|
# ? Jul 11, 2017 20:22 |
|
Oscar Wilde Bunch posted:When you create a new profile it does seem to give a little bit before it stops working right, but that time period can be like 30 minutes. You mention Outlook 2016, how do other versions behave? You can go down as low as 2010 connecting to O365, though you lose a few features here and there. Might be interesting to see if there are quirks that only manifest in the newer versions so you have somewhere to look. You are on the latest patch level of Office, or should be when troubleshooting hard to find stuff like this. But try the latest build, maybe even insiders if you have it, and see if it goes away because that has been the solution to quite a few of hard cases I encountered. That a new profile gives temporary relief is an indication that something might be messing with profiles after they're made. Which antivirus do you run, and can you arrange a testing situation without antivirus for an affected user? By that I mean find a fresh machine where the regular AV isn't even installed because disabling doesn't always actually do the job entirely. Is there anything in either of these locations in the registry? HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Cached Mode HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Cached Mode Last one, sorry for the barrage of questions, you can move mailboxes between databases in Exchange Online, though it's not widely know/done. Did you try that? If you're on prem you definitely should but since you mention O365 support I assumed Online. You can simply enter into an Exchange Online Powershell session: code:
|
# ? Jul 11, 2017 20:22 |
|
Old Binsby posted:You mention Outlook 2016, how do other versions behave? You can go down as low as 2010 connecting to O365, though you lose a few features here and there. Might be interesting to see if there are quirks that only manifest in the newer versions so you have somewhere to look. You are on the latest patch level of Office, or should be when troubleshooting hard to find stuff like this. But try the latest build, maybe even insiders if you have it, and see if it goes away because that has been the solution to quite a few of hard cases I encountered. The only issue with downgrading now is that they won't support anything below 2016 anymore, as I think 2013 rotated out in ?June?. We're Exchange Online. We've tried moving the mailboxes between databases. We've tried machines with no AV period and it doesn't seem to do anything. There's nothing in those settings, though I'm going to try out with the policy to change the default cached mode timings, as it seems that my problem essentially some kind of failure in that area. It's like the client just forgets to ask if there's anything new out there, unless it prompted to do so, or some arbitrary time has passed.
|
# ? Jul 11, 2017 20:49 |
|
Does a non domain-joined PC do this? Crufty old GPO causing problems maybe?
|
# ? Jul 11, 2017 21:16 |
|
Oscar Wilde Bunch posted:The folder shows Up to Date, Connected to: Microsoft Exchange. When someone is having the problem, hold CTRL and right click the Outlook icon in the system tray. That'll bring up the connection status window. Are all the connection established or is one or more connecting/disconnected? If you click on reconnect does that fix the problem temporarily?
|
# ? Jul 11, 2017 21:34 |
|
Thanks Ants posted:Does a non domain-joined PC do this? Crufty old GPO causing problems maybe? I'll try this next. I've got plenty of PC's I can use to just like sit it in a users office and see if the Outlook's disagree. As far as GPO's go, there's one for password policy and that's it. Any GPO like stuff is done though Desktop Authority. Will Styles posted:When someone is having the problem, hold CTRL and right click the Outlook icon in the system tray. That'll bring up the connection status window. Are all the connection established or is one or more connecting/disconnected? If you click on reconnect does that fix the problem temporarily? It shows like it would if everything was normal. That's the worst part of figuring this out. The client is just tooling along thinking everything is OK.
|
# ? Jul 11, 2017 21:48 |
|
Oscar Wilde Bunch posted:The only issue with downgrading now is that they won't support anything below 2016 anymore, as I think 2013 rotated out in ?June?. We're Exchange Online. We've tried moving the mailboxes between databases. We've tried machines with no AV period and it doesn't seem to do anything. Outlook 2010 is interesting because I thought that was the quickest way to check out the difference between connections via the old protocol (MAPI over) RPC over HTTP and the newer MAPI over HTTP. It turns out later versions can also still do that. Troubleshooting while still supported, hurray! Done by adding the following REG_DWORD with value 1: HKEY_CURRENT_USER\Software\Microsoft\Exchange\MapiHttpDisabled It's a real long shot but you never know? The connection status screen (I'm guessing you know this but for completeness' sake) is opened by ctrl+right clicking the outlook icon in the system tray near the clock, the protocol should read RPC/HTTP instead of the default 'MAPI/HTTP' after the change above. If you always saw RPC/HTTP that's a red flag too, but you or Microsoft would have noticed that. Are request, fail, latency numbers all equal between good/bad clients? Also, you mentioned looking quite deep into the MAPI protocol and finding nothing. But did you see periodic communication between client and server at all? O365 support should also be able to analyze the troubleshooting logs that you can enable. Did they do so and find nothing? You can always try yourself by pulling the ETLs through tracerpt but it's hard to predict if that'll work properly. These kind of issues are fun in a way when they stump the supplier support teams as well. But your support engineer ghosting you, never replying at all is pretty bad. If you have a technical account manager, try raising the issue with them. They might involve different engineers or move this toward another support team (i.e. Outlook instead of O365), although you're probably already at the right guys. Otherwise: Did you capture any network traces? Significant differences in the number of timeouts or retransmissions could point to a network issue after all. e. typo Old Binsby fucked around with this message at 21:59 on Jul 11, 2017 |
# ? Jul 11, 2017 21:57 |
|
Doesn't Desktop Authority still use GPOs, but provides are more user friendly and configurable interface on top?
|
# ? Jul 11, 2017 21:57 |
|
Oscar Wilde Bunch posted:I'll try this next. I've got plenty of PC's I can use to just like sit it in a users office and see if the Outlook's disagree. When the email starts to arrive again, does it happen on all the affected clients at the same time? Like one minute they all just start being able to receive email again, or is there no relationship like that.
|
# ? Jul 11, 2017 21:58 |
|
Old Binsby posted:While MAPI is extremely relevant in Exchange still, it's hard to get to a point where it is the cause of something loving up. I'd guess this LOB app, if it's written in the past couple years, will probably be using EWS to make a connection over https to Exchange and do its thing. You can try to figure this out through documentation or by wiresharking and checking for connections to [url]https://[/url][exchange server name or load balancer FQDN]/EWS/exchange.asmx. Maybe, I never tried, you can proxy them through fiddler to see the contents too. Nah, it's definitely still MAPI. It was written... Probably around 10 years ago? and hasn't changed significantly since then. Writing the issue out though, I kind of went "duh, of course it's the public folders issue." I showed it to the tech originally responsible for trying to get the client's MSP to fix their poo poo, and he laughed and said that's not even the local address of their current server, it's the one they upgraded from a few months ago, which is what started this whole mess. We're going to pursue that for now.
|
# ? Jul 11, 2017 23:31 |
|
Oscar Wilde Bunch posted:Desktop Authority.
|
# ? Jul 11, 2017 23:31 |
|
Thanks Ants posted:When the email starts to arrive again, does it happen on all the affected clients at the same time? Like one minute they all just start being able to receive email again, or is there no relationship like that. Pray it isn't something as insane as this: https://www.reddit.com/r/networking/comments/20ew5s/bad_ethernet_cable_causes_only_outlook_to_fail_why/ Hell at this point, I'd almost try to rule out your entire connection / network / firewall etc. completely just for grins - tether an affected system to a 4G hotspot for connectivity (use your cell phone, pick up a cheap Cradlepoint router etc.), see if the issue still occurs. Beyond that, I know I'd start running some packet captures on baseline working systems, then compare with packet captures on these systems exhibiting issues. Depending on your firewall you could run some packet captures on the firewall with a capture filter of the IP address of one of the affected systems. It's tough to say if you are diving down the rabbit hole of digging TOO deep in the network, versus looking at this as an OS/application specific issue, but might still be worth a shot.
|
# ? Jul 12, 2017 03:21 |
|
A Pinball Wizard posted:
Can you elaborate in this for me? It sounds like something my org is dealing with in our ExOL migration.
|
# ? Jul 12, 2017 06:25 |
|
can you set cost / priority for connectors in Exchange Online? Can't find any documentation that says I can.
|
# ? Jul 17, 2017 21:52 |
|
Mutar posted:Can you elaborate in this for me? It sounds like something my org is dealing with in our ExOL migration. I don't know that I can, because I'm very not an exchange guy, but basically we can set up the account in Outlook and access the inbox fine, but not access public folders. When I look at the message stores in mfcmapi the main mailbox shoes the correct server in the legacyDN and a couple other places, but the public folders show the old server name in the same places. No idea how to fix it, but technically I don't have to, I just have to tell the customer what's wrong and to contact her MSP.
|
# ? Jul 17, 2017 22:05 |
|
A Pinball Wizard posted:I don't know that I can, because I'm very not an exchange guy, but basically we can set up the account in Outlook and access the inbox fine, but not access public folders. When I look at the message stores in mfcmapi the main mailbox shoes the correct server in the legacyDN and a couple other places, but the public folders show the old server name in the same places. No idea how to fix it, but technically I don't have to, I just have to tell the customer what's wrong and to contact her MSP. I can't offer any advice here, but I'm genuinely curious what kind of position or relationship you have with your customer to be digging this deep into an Exchange problem when you're neither an Exchange person, nor the customer's MSP.
|
# ? Jul 18, 2017 02:19 |
|
Found it, never mind! Matt Zerella fucked around with this message at 16:00 on Jul 18, 2017 |
# ? Jul 18, 2017 15:22 |
|
nexxai posted:I can't offer any advice here, but I'm genuinely curious what kind of position or relationship you have with your customer to be digging this deep into an Exchange problem when you're neither an Exchange person, nor the customer's MSP. Oh man, it's loving great. We basically offer access to our LOB app in a terminal service environment that includes Outlook. The original issue was anytime they tried to access e-mail using our app, it would prompt them to enter a username and password, and if they didn't enter it everything would break horribly until they re-created their e-mail profile. Their MSP - someone our sales team recommended - is the one who migrated them to their new exchange server, and has insisted the entire time that nothing is wrong on his end because everything works fine in Outlook (spoiler: it doesn't, actually), so we need to fix it, and he's going to charge the customer $300 for a service call if we want him to change anything on the server. Customer is pitching a fit because WE PAY YOU $5000000000000 A MONTH FIX THIS NOW!!!, it's gone up to the SVP level at this point, who basically said "We have an exchange admin of our own, right? Why not get him to fix it?" That turned up such issues as: -UPNs different from SAM account names -No external virtual directories set up -Internal authentication type different from external (this turned out to be the main issue with integration with our software) We fixed the second two issues for them on their server, and the only outstanding issue is the one I'm working on, which I found out we're probably also going to end up fixing for them. It is a very unusual case and not something we normally do.
|
# ? Jul 19, 2017 03:25 |
|
I see this with MSPs all the time, just straight up not configuring poo poo correctly. They go through the wizard and if somehow something works in the end then the job's done.
|
# ? Jul 19, 2017 07:18 |
|
It's because nobody who knows what they are doing sticks around at an MSP, the industry is all about giving people at the start of their careers poo poo pay and conditions to maximise profit during the contract period the customer has signed up for, then repeating it with another customer and another set of new hires.
|
# ? Jul 19, 2017 08:15 |
|
Why in the world would someone be using Bounce Address Tag Validation (BATV) in YTOOL2017?
|
# ? Jul 21, 2017 00:05 |
|
Internet Explorer posted:Why in the world would someone be using Bounce Address Tag Validation (BATV) in YTOOL2017? They might be on Old Software? It is the year 2017 but I run into it mostly on that. This very year I decomissioned ForeFront TMG and Protection For Exchange servers someplace. Mainstream support ended ~two years and as far as I can tell neither were receiving spam nor malware signature updates anymore. This was apparently not that big of a problem. Luckily, Forefront did do backscatter protection so they were safe from that! Moved them to EOP for email which introduced BATV as a 'new feature' in... 2015. So it's not dead but there are better ways to check where mail came from and whether you should accept the NDR these days. (effortpoast coming up - tldr: what email security is Good????) I always feel a little bad moving small-medium sized clients to Exchange Online Protection. I get why they do it, it's super easy to sell for MS (cause it's free with most enterprise licenses ). And honestly, not much will change is the customer is coming from old MS email filtering services but otoh it's mediocre to bad, in my opinion. There's too little granularity so I'm nearly always either blocking OR letting through way too much without a good middle ground. There's no integration with SIEM-like security software - which is usually also kind of convoluted stuff but at least it gives the actual security guys easy access to mail-related events. But who cares, as long as it stops the spam and malware. It doesn't really do that too well either, though... While Exchange is kind of my thing, email security isn't so any practical knowledge is welcome. What's the Good Email Security Solution these days? I know only one alternative well enough to say anything about that, which is Forcepoint (formerly WebSense). I kind of like this but would not wholeheartedly recommend. Mostly because it is actually good at catching malware and spam and has pretty detailed rules for all sorts of scenarios built in. At least, comparing side by side during a PoC deployment I've seen it is noticably better at filtering spam and recent viruses than an EOP test instance (which is a low bar). Not super expensive, has a sandbox service to check executable content. Downsides are that, at least on Windows Server, it has no real command line interface for deployment, management nor automation as far as I could tell, which is a no go to me (you could clone xml configurations but... meh). It's also a terribly convoluted GUI that feels like several dozen mergers ago, there were 12 seperate programs that worked well but now someone superglued them together. Also you end up with a locally hosted management web service, on a box with literally 3 kinds of web servers, 3 different database engines, all sorts of weird prerequisites. It's kind of ugly. Also used symantec message labs for 2 days once, which was awesomely slow and featureless. It might be better now? Is proofpoint as good as all the marketing says?
|
# ? Jul 24, 2017 01:52 |
|
Old Binsby posted:what email security is Good????
|
# ? Jul 24, 2017 04:21 |
|
anthonypants posted:Mandatory TLS 1.2 is pretty good, imo. Yes. you're right. That's not what I meant, but that's a good idea (until someone VITAL TO OUR BUSINESS, LITERALLY INDISPENSABLE can't do TLS 1.2 on his vintage Notes server). Make me happy, share your favorite email malware/threat/spam detection software. Or least favorite, that's cool too.
|
# ? Jul 24, 2017 04:44 |
|
Google do some neat stuff with their filtering but they've killed off Postini so that's not really an option for people who want to use Exchange
|
# ? Jul 24, 2017 09:37 |
|
While the security team does the daily administration of Proofpoint, I'm pretty satisfied with it from the perspective of both an end-user and email admin. We get a digest every couple of hours listing everything in quarantine, and you can release it then and there from a link in the email if need be. Takes the "can you check the spam filter" helpdesk request and throws it right the gently caress out the window. The only thing I've seen slip past are some very well crafted it marketing emails, but then again my email has only existed for 3 months so it's not on the real nasty spam lists yet. Implementation was relatively easy, though ymmv depending on how complicated your mail environment is. I put it in place in conjunction with ripping out our legacy on-premise environment, so our implementation time took a bit longer than an already stable setup.
|
# ? Jul 24, 2017 13:32 |
|
devmd01 posted:While the security team does the daily administration of Proofpoint, I'm pretty satisfied with it from the perspective of both an end-user and email admin. I always like the idea of users releasing and reviewing mail in junk quarantine themselves but in practice, doesn't it open you up to users shooting you and themselves in the foot opening bad things because they think it's legit? Some spearphishing/regular old phishing stuff these days are really well done, they trip up most anyone I know. Not too proud to admit being fooled once myself by an internal security audit by some white hat firm which was reallywell done -- they got some kind of fuckup out of 90% of my fellow IT dudes (the remaining 10% prob survived because they ignore email entirely and only communicate through Slack/skype f b)
|
# ? Jul 24, 2017 14:14 |
Am I missing something with well known folders, specifically contacts? I'm just attempting to isolate contacts in a pst for an import and -sourcefolder "#contacts#/*" gives me nada while "contacts/*" works. Have to ID a targetrootfolder for any copy to exist but the root folder shows as a mail folder rather than contacts and the contacts come in as was in the source PST (not nested or in the targetrootfolder). I feel like I"m taking crazy pills. I think I can avoid the -targetrootfolder creating an empty shell folder issue by using the folder "/" but that may merge contacts and I'm taking a step back before loving around further. so in shot New-MailboxImportRequest -Mailbox Submarine -filepath \\Sandpaper\Share\PSTImport\Personal.pst -IncludeFolders "contacts/*" -targetrootfolder "Import" the above works, creating an empty root folder "import" in the user's mail and however contacts were setup in personal.pst shows up in the contacts list, doesn't merge. New-MailboxImportRequest -Mailbox Submarine -filepath \\Sandpaper\Share\PSTImport\Personal.pst -IncludeFolders "contacts/*" Does not work New-MailboxImportRequest -Mailbox Submarine -filepath \\Sandpaper\Share\PSTImport\Personal.pst -IncludeFolders "#contacts#/*" -targetrootfolder "Import" Does not work wtf I've also tried targetrootfolders of "#contacts#/import" but that fails. I want to use well known names to avoid having to check that the user's pst is english.
|
|
# ? Jul 27, 2017 16:49 |
|
I have a minor issue that is hopefully easy to solve. Environment is Exchange 2013/CU10, and is currently in otherwise normal working order. We recently decommed a server, for which Exchange was gracefully uninstalled via Add/Remove Programs. The server is no longer listed in EAC's list of servers, and the VM has since been removed from disk. It is completely unrecoverable. Clients do not experience any issues connecting. However, whenever I log into EAC, I receive the following alert in the upper right, displaying the now-decommed server and cert: Clicking "View details" takes me to Servers > Certificates. The decommissioned server displayed in the alert is not listed in the "Select server" dropdown menu, and the page defaults to the first server in the list. The decommed server is not listed in Servers > Servers in EAC, nor is there an AD object for it. The decommed server is not listed in ADSIEdit under CN=Servers,CN=Exchange Administrative Group (xxxxxxxxxxxx),CN=Administrative Groups,CN=<BusinessName>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<DomaiName>,DC=com I haven't found much by looking around online, and "Uninstall Exchange before decomming the server" is the commonly-cited fix for this issue, but I did that. Any help is appreciated! OpaqueEcho fucked around with this message at 22:50 on Aug 2, 2017 |
# ? Aug 2, 2017 21:45 |
|
Submarine Sandpaper posted:Am I missing something with well known folders, specifically contacts? # is a global comment out for powershell. You can use code:
code:
incoherent fucked around with this message at 23:42 on Aug 2, 2017 |
# ? Aug 2, 2017 23:39 |
|
OpaqueEcho posted:I have a minor issue that is hopefully easy to solve. In order of easiness to check - open an Exchange powershell session. Check output for Get-ExchangeCertificate for each internal server (use the -server parameter or you just get local output from your powershell proxy) Do you see the thumbprint/friendly name from your screencap? Get the output for Get-SendConnector. Check if the server's still listed as a source somewhere and whether had a dedicated connector that got corrupted or wasn't removed. - if not, you check the computer cert stores on remaining exchange servers, maybe it's still there somewhere - if it's not there, it can hardly be bound to any service in IIS either but you should check there if it's still configured somewhere whatever means - If it's not, check your Edge servers if you have them, the edge subscription can give weird errors if an internal host is decommissioned without removing the server from EdgeSync first. (though usually on the Edge, not the LAN). It'll show up in Get-Queue as a nexthop for a queue and also in the event viewer if removal is done improperly with errors die to sync failures - check for the cert on your reverse proxies, if applicable Hope you're getting somewhere by that time, but if not I'd be happy to think of a few other suggestions. This is where I'd start. E. Submarine Sandpaper posted:New-MailboxImportRequest things This cmdlet consists nearly entirely of gotchas and very little regularity. Few things I've stumbled over (this is all here, but kind of vaguely worded): -targetrootfolder and sourcerootfolder are 1 folder, can't be a deeper tree, so they're always at the top level of the mailbox. Can't use wildcards in them. You do not need to use these if you're merging entire mailboxes -includefolders and excludefolders also don't take wildcards. They accept a collection of strings as input, which may be a one or more trees of folders but they must be written out and not wildcards. You can try to do this with get-mailboxfolderstatistics but it won't be a pretty one-line thing -the quotes thing above has merit but there's more to it than that. You can definitely nest quotes of the same type, just need to escape them. The # might also need the escape character, the accent grave (`) does this in powershell. I used the localized folder names exactly once and it was kind of bad I remember, so I'm not sure. Old Binsby fucked around with this message at 00:19 on Aug 3, 2017 |
# ? Aug 2, 2017 23:48 |
|
Got a horrible issue that I took over: Exchange Online - no dirsync/adconnect (fully cloud) a user was having issues with her phone and as part of troubleshooting MS support advised the tech to remove the X.500 address from the user properties. Since that has happened, the user's ASSISTANT is not able to edit recurring meetings that were scheduled prior. Error: "you are not allowed to send on behalf of". I don't know what the x.500 address was. What can I do? edit: The assistant is listed as having send-as, send-as-behalf-of, and full access to mailbox. The assistant can edit meetings created AFTER this happened. Dans Macabre fucked around with this message at 16:36 on Aug 23, 2017 |
# ? Aug 23, 2017 16:30 |
|
Did you try to download the GAL again for the assistant? I've seen weird issues like that get resolved that way.
|
# ? Aug 23, 2017 16:53 |
|
Jeoh posted:Did you try to download the GAL again for the assistant? I've seen weird issues like that get resolved that way. I'm on a fresh profile. Furthermore: when the user herself cancels an old meeting, it lets her, and then she gets bounceback e.g. pre:This message could not be sent. Try sending the message again later, or contact your network administrator. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-0x0004dc-0x000524].
|
# ? Aug 23, 2017 17:16 |
|
Old Binsby posted:<lots of good suggestions and advice> Thanks for the reply and help! I ended up resolving the issue by rebuilding the Arbitration mailboxes.
|
# ? Aug 23, 2017 19:00 |
|
|
# ? May 2, 2024 21:41 |
|
NevergirlsOFFICIAL posted:I'm on a fresh profile. Furthermore: when the user herself cancels an old meeting, it lets her, and then she gets bounceback e.g. Did you remove the X500 address value from the AD proxyaddresses attribute or did you empty the ExchangeLegacyDN for the user? Either way, a lot of weird poo poo starts happening when you start removing these addresses due to ~~legacy routing protocols~~ in exchange. This blog goes into it a bit. You can probably fix it by re-adding the previous (not their current) on-prem LegacyExchangeDN attribute for the user as an X500 address to the proxyaddresses field (prefix it with 'X500:') but I don't have enough information to be sure here and you might have had a good reason to remove it (just read you also don't have it anymore, though most likely you can extract the old X500 address from the NDR). So probably the smartest thing to do is wait for the Exchange servers to update the GAL or force an update, and then clearing your clients local address cache (starting from a clean profile is fine). Alternatively, you can have them connect in online mode, without cache so you don't have to wait for that or use OWA to take the client out of the equation. If that doesn't work, remove permissions and re-add them, especially Send on Behalf (through the the outlook Delegate window, calendar permissions are likely to not work otherwise) due to that being an AD backlink attribute which break when you migrate a user with a SID history and/or [...]. It's kind of messy, not going to post thousands of words unless anyone is actually interested . It's inevitable you run into this kind of problems during migrations which is why MS won't support cross-prem permissions and/or send on behalf permissions after migrations. e. OpaqueEcho posted:Thanks for the reply and help! I ended up resolving the issue by rebuilding the Arbitration mailboxes. Huh, cool. Something to keep in mind if I ever run into weird decommisioning issues. Old Binsby fucked around with this message at 20:00 on Aug 23, 2017 |
# ? Aug 23, 2017 19:55 |