|
NevergirlsOFFICIAL posted:I have an Exchange Online client with Mimecast. I want Exchange to never move messages to Junk Email folder because Mimecast should be handling that. This is a Mac environment so I cannot do my usual GPO for this. https://community.mimecast.com/docs/DOC-1608#jive_content_id_Bypassing_Spam_Checks
|
#
?
Oct 31, 2017 18:25
|
|
|
|
| # ? Apr 19, 2024 18:08 |
|
|
Thanks Ants posted:Have you done this? yes - I don't believe this really bypasses everything though. maybe I'm wrong.. but doesn't the mailbox do some of its own spam processing soemhow?
|
|
#
?
Oct 31, 2017 18:37
|
|
|
NevergirlsOFFICIAL posted:yes - I don't believe this really bypasses everything though. maybe I'm wrong.. but doesn't the mailbox do some of its own spam processing soemhow? code:code:
|
|
#
?
Oct 31, 2017 18:40
|
|
|
NevergirlsOFFICIAL posted:yes - I don't believe this really bypasses everything though. maybe I'm wrong.. but doesn't the mailbox do some of its own spam processing soemhow? It shouldn't be getting flagged as spam at all. Does the message trace show what's happening at all?
|
|
#
?
Oct 31, 2017 18:42
|
|
|
NevergirlsOFFICIAL posted:I have an Exchange Online client with Mimecast. I want Exchange to never move messages to Junk Email folder because Mimecast should be handling that. This is a Mac environment so I cannot do my usual GPO for this. That setting specifically can be handled administratively, see below: anthonypants posted:Connect to Exchange Online via PowerShell and run this: However, users can still log into OWA\Outlook and turn junk email back on. You could write a script that runs every night and turns it off for anyone who has it on, or you could make a transport rule that sets everything coming in from the mimecast server to have an SCL of -1 so that if someone turns the feature back on the messages still won't go to junk mail.
|
|
#
?
Oct 31, 2017 19:21
|
|
|
anthonypants posted:Connect to Exchange Online via PowerShell and run this: perfect thank you
|
|
#
?
Oct 31, 2017 19:54
|
|
|
Thanks Ants posted:It shouldn't be getting flagged as spam at all. Does the message trace show what's happening at all? gently caress ok, you caught me, I was going by user reports without verifying. shame on me.
|
|
#
?
Oct 31, 2017 19:55
|
|
|
I use an Exchange 2016 server just to allow me to manage email addresses and groups because we host our email on Office 365 but we used to host it internally (best practices are not to get rid of Exchange if you migrated to O365 from internal hosting). I thought I had lost the server I was using, so I had to start removing references to it in Active Directory in order to install Exchange on a new server. As it turns out, all is not lost on the old server (it's a long story). Is there some way for me to force the correct references for the old Exchange server back into Active Directory without having to do a reinstall? Like is there a tool anyone knows of that will go through Active Directory and update the needed records? I just need the mailbox function active for things to work correctly in order to correctly synchronize email users with Azure Active Directory/Office 365 email.
|
|
#
?
Nov 1, 2017 16:15
|
|
|
I'm not aware of any tool that will do what you want. Microsoft doesn't have one because their expectation is that if you want/need to remove an Exchange server you're using the uninstall method, and if that's unavailable you recover the machine using the install media. There may be some third party stuff that claims to do everything, but since Microsoft doesn't document exactly what attributes in AD change when you install an Exchange server the tool may be and probably is incomplete. In my opinion your best bet is to bite the bullet and install a new server.tadashi posted:I thought I had lost the server I was using, so I had to start removing references to it in Active Directory in order to install Exchange on a new server. In the future if you lose an Exchange server you can run the install media on a new server using the /m:RecoverServer switch that will reinstall Exchange on that server looking at AD to see what kind of server it is. This may still work with your current situation but it uses the information in AD to perform the installation so depending on what you've manually removed it may or may not work. More info on the recovery switch here.
|
|
#
?
Nov 1, 2017 16:47
|
|
|
Will Styles posted:I'm not aware of any tool that will do what you want. Microsoft doesn't have one because their expectation is that if you want/need to remove an Exchange server you're using the uninstall method, and if that's unavailable you recover the machine using the install media. There may be some third party stuff that claims to do everything, but since Microsoft doesn't document exactly what attributes in AD change when you install an Exchange server the tool may be and probably is incomplete. In my opinion your best bet is to bite the bullet and install a new server. I did find that solution and tried it after I thought I'd lost the original server. For some reason, the recovery installation kept failing because it kept finding the existing references for the connectors. Things got nasty pretty quickly. When I abandoned that, I started trying to manually clean things up so I could install on a new server. I find so many problems with MS Exchange that have been around forever and it really drives me insane that Microsoft is making so much money off a product that is still pretty lovely (see thread title, I guess).
|
|
#
?
Nov 1, 2017 17:59
|
|
|
Our CEO’s assistant needs to be able to access the CEO and VP’s mailboxes that when combined with her mailbox, total over 70Gb. Additionally, she exceeds the “limit” of 500 folders by a factor of 2 or 3 with her mailbox alone. Both the CEO and VP’s folder counts are extremely high as well, due to the same type of organizational system being applied to their mailboxes. Unfortunately, this person has been the single biggest reason why it has been a major hurdle trying to get buy in on finally enabling a two year retention policy after years of trying. The VP's mailbox is now down from somewhere in the 20-40gb range down to 10gb. I'm guessing that once I can enable the retention policy on the assistant and CEO, the combined size for 2 years of mail will be roughly 25-35Gb in total. Large, but under the 50gb limit and likely okay. Last week, she ran into problems with mail synchronization stopping without manually sending and receiving, which according to OffCAT was due to the number of cached folders being 1047. Disabled cached exchange mode, but that doesn't really fix the issue. We’re currently piloting O365 and have a 2010 hybrid configuration in place. Her mailbox, along with the CEO and VP are still on-prem. The current plan/strategy for accessing old email is by using our Barracuda Email Archiver when paired with the Outlook plugin and folder sync. It synchronizes mail to an additional mailbox and a separate .NST file, retains the folder structure, and seems to work pretty well. Microsoft lists adding additional mailboxes as additional Exchange accounts rather than via full access permission/auto-mapping or by adding the account via advanced mailbox settings in this article: https://support.microsoft.com/en-us/help/3115602/performance-problems-when-you-try-to-access-folders-in-a-secondary-mai TLDR; I'm trying to figure out the best course of action for an assistant who has been running into problems due to way too many folders between her mailbox, and the CEO and VP mailboxes she also opens. Looks like the 500 folder limit is actually a limit for open MAPI sessions. The three mailboxes combine have nearly 2400 folders. Looks like they deleted a few hundred folders since last week. Has anyone ever significantly bumped up the MAPI session limit? There was a spiceworks thread about someone who had no issues bumping it up to 7500, however I don't exactly trust spiceworks. I've stumbled onto some seriously stupid commentary on there regularly. ...not that I browse Spiceworks. There's some background info above if you're curious, but digging into it more, it's clear that the issue is specific to the number of folders when paired with cached Exchange mode. Also - any reason I should consider online archive mailboxes instead of using our Barracuda Archiver?
|
|
#
?
Nov 13, 2017 22:15
|
|
|
any chance she can do something like just access CEO's mailbox in outlook, and her own mailbox in OWA?
|
|
#
?
Nov 14, 2017 13:01
|
|
|
What’s the best 2FA solution that will work with outlook 2016? I tested azure MFA and it worked fine but broke outlook a little.
|
|
#
?
Nov 14, 2017 13:26
|
|
|
If this is Exchange Online, did you enable Modern Auth?
|
|
#
?
Nov 14, 2017 15:38
|
|
|
Thanks Ants posted:If this is Exchange Online, did you enable Modern Auth? I thought it was enabled by default! I just checked and NO it is disabled. If I enable it will it break anything?
|
|
#
?
Nov 14, 2017 15:46
|
|
|
Enabled by default on tenants created in 2017, not documented widely (yay). I would expect people to re-authenticate in Outlook (iOS/Android already use modern auth).
|
|
#
?
Nov 14, 2017 17:33
|
|
|
NevergirlsOFFICIAL posted:any chance she can do something like just access CEO's mailbox in outlook, and her own mailbox in OWA? Anyone have a really, really good understanding of calendar permissions and ExFolders? I've stumbled onto some calendar sharing permission problems. From powershell, it appears problem users should be able to access certain other users' calendars as they have availabilityonly permissions explicitly set, as well as the default permissions being availabilityonly for the calendars. However, they get an error about the calendar not existing or not having permissions. Both on-prem to on-prem and with on-prem <-> o365 mailboxes. Although our o365 consultant claims it should be fully functional, everything I've read thus far indicates that a) non-explicit permissions do not get migrated and b) cross premises permissions are only work when using full access permissions. Also, while our handful of migrations had no errors, digging into it now, it looks like we have a bunch of skipped items for corrupt ACL's. This ought to be fun............ goobernoodles fucked around with this message at 18:24 on Nov 14, 2017 |
|
#
?
Nov 14, 2017 18:15
|
|
|
goobernoodles posted:Nope. I suppose I could set up a second machine for her, but... bleeeggghhhhh... I think I'll give the MAPI session increase a shot. You're right about that last bit: cross prem permissions are a crapshoot (and they're mostly not supported) but Full Access work most of the time. I've had weird permission issues crop up while migrating, most significantly that whatever is in the GrantsSendonBehalfTo attribute may be a SID on-prem or it might be the SID history attribute for a user. Once you migrate the users where the latter is used for send on behalf delegation, there's no chance those permissions still work afterwards. If authenticated users can't see free/busy data when the default user permission is set to allow that, there's probably some hybrid connectivity issue The folder limits you're running into with the veep/assistant suck to troubleshoot. I remember something about Outlook keeping less/no folder connections open for archive mailboxes. Is it an option to dump a bunch of old mail in there?
|
|
#
?
Nov 18, 2017 03:59
|
|
|
I'm running into a certificate problem that I can't untangle. I have a server called MX1.int.mycompany.com and it has a wildcard cert for OWA access assigned for *.mycompany.com. External access to mail.mycompany.com/owa works fine, but internal access via outlook throws up a security alert because the name on the cert (*.mycompany.com) doesn't match the name of the server (mx1.int.mycompany.com) due to me following MS best practices on using subdomains. I can't find a place where I can assign a cert for external virtual directories and a different cert for internal access. Can anyone help?
|
|
#
?
Nov 22, 2017 19:24
|
|
|
Don't use a wildcard, use a SAN cert.
|
|
#
?
Nov 22, 2017 19:27
|
|
|
Thanks Ants posted:Don't use a wildcard, use a SAN cert. I thought about that, but I already have a wildcard cert for mycompany.com and since this is a personal project I won't be buying another.
|
|
#
?
Nov 22, 2017 19:55
|
|
|
I don't know what the approved method for handling that problem is when using subdomains, other than like Thanks Ants said, using a SAN cert that includes both FQDNs, but I would approach the problem similar to how I would approach it when using a .local domain. Split-brain DNS - an internal DNS server that has a mycompany.com domain that points to the internal IP of MX1.int.mycompany.com. Or possibly NAT loopback? I think either solution would work. I'd go the NAT loopback route first, easiest to set up with the least amount of drawbacks.
|
|
#
?
Nov 22, 2017 20:18
|
|
|
Agrikk posted:I thought about that, but I already have a wildcard cert for mycompany.com and since this is a personal project I won't be buying another. Let's Encrypt will give you a SAN cert.
|
|
#
?
Nov 22, 2017 20:48
|
|
|
Agrikk posted:I'm running into a certificate problem that I can't untangle. Exchange with wildcard certs is fraught with peril and you've stumbled upon a common pitfall. Although your issue isn't Exchange-specific, quoting http://www.ietf.org/rfc/rfc2818.txt quote:If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. assigning two different certs isn't supported btw, you can manually do that in IIS but the settings might not persist and they'll definitely revert when you apply a CU. Your split DNS unfortunately needs SAN certificates. It isn't a terrible practice to not do split brain though Old Binsby fucked around with this message at 15:04 on Nov 25, 2017 |
|
#
?
Nov 25, 2017 14:58
|
|
|
Anyone here using duo with outlook on the FAT client? Would love to hear experiences.
|
|
#
?
Nov 28, 2017 23:26
|
|
|
Alternately is there anyway I can say that only domain joined workstations can use fat client
|
|
#
?
Nov 28, 2017 23:26
|
|
|
NevergirlsOFFICIAL posted:Anyone here using duo with outlook on the FAT client? Would love to hear experiences. We're using DUO on our ADFS implementation, which would apply to the thick client. There really isn't much to it. As long as the only profile you sign into is on the same ADFS you won't really hit any issues. The bigger issue is once you've enabled it for users other applications stop working that don't support modern auth unless you put in a bunch of claims rules to ignore those clients.
|
|
#
?
Nov 28, 2017 23:42
|
|
|
I've managed to figure out the certificate issue using an ELB in front of the edge servers that avoids using the subdomain. It's kludge, but it works. The next issue I have is that DAG doesn't seem to be working properly, or my understanding of an Exchange DAG is wrong (both are equally possible). I have MX1 and MX2 with Database1 and Database2 running in a DAG using a share on Witness1 as a quorum. It appears to be set up right as I see data in the share, and each exchange server has two database directories. MX1 was the original Exchange server and I added MX2 and Witness1 when I built the cluster. I have User1 associated with Database1 with the primary host on MX1 and User2 associated with Database2 on MX2. When I shut down MX2, everything for User2 breaks (I can't connect to exchange through OWA or Outlook to see if email is being delivered properly) but User1 operates normally. Similarly, when I shut down MX1, everything for User1 breaks. However, when MX1 is down, User2 cannot send or receive email. Isn't the whole point of a DAG to create redundancy, so that if a member server goes down the cluster stays up and keeps client access running? What have I missed that is causing the dependency of User2 on MX1 as well as User2/User1 not being able to reach email when MX2/MX1 is down?
|
|
#
?
Dec 6, 2017 02:35
|
|
|
NevergirlsOFFICIAL posted:Alternately is there anyway I can say that only domain joined workstations can use fat client You can make it harder for fat clients to get in by not publishing the default autodiscover DNS-records internally, which is kind of fiddly but domain-joined will lookup the custom location via AD in the Service Connection Point Exchange publishes. Enforcing kerberos or certificate based authentication (bit of a pain) and disallowing NTLM/basic everywhere except OWA/ECP cuts down on workgroup devices getting in but that's independent of client type. Outlook Anywhere/ActiveSync may still be an option for non-domain joined machines of course Agrikk posted:I've managed to figure out the certificate issue using an ELB in front of the edge servers that avoids using the subdomain. It's kludge, but it works. Bold part: yes, mostly italic: no, the client access proxying exchange does can be done with no DAG at all but you're right in the general sense. However DAGs don't provide 100% hands-off always-online databases resilient out of the box. The DAG keeping a second copy is primarily useful if you need to bring down a host in a controlled manner: You can switch over database to its passive copy, drain client connections and advertises a new host by not renewing them on the server going down and the user won't notice a thing while you do maintenance. Whether a DB will switchover automatically when a host goes down is dependent on the DatacenterActivationMode and probably their activation policy and a couple things I forget right now because it's late. Anyway yess, DAGs provide HA but with some caveats, it's always better to fail over in a controlled way Users dropping connectivity when you drop a hot while their mailbox database server is still up means that they were being proxied through the client access service on the machine you killed. Set-ServerComponentState before or after will probably help you there, though be aware that undrained servers will usually leave a bit of a messy impression on the users when you simply say 'gently caress it, serverwideOffline and lunch time'. Probably going to be a few PW prompts etc, maaaaybe some Outlook profile corruptions. also to make sure I completely resemble the MSFT community support people here are some mediocre documentation links on DAC mode (Technet) you probably found on your own already Old Binsby fucked around with this message at 03:31 on Dec 6, 2017 |
|
#
?
Dec 6, 2017 03:08
|
|
|
Thank you for that write up. Exchange group never really got on board with the OS level clustering and availability like SQL and Sharepoint does. Maybe 2019 will fix that.
|
|
#
?
Dec 6, 2017 21:32
|
|
|
So what are my next steps to get rid of our remaining on-prem exchange environment, without blowing up any existing exchange attributes? How does management work after you no longer have an exchange server on-prem? - All user mailboxes are in O365, most migrated from on-prem - Nearly all distros, etc are synced to O365 - All mail traffic inbound/outbound to the internet from O365 goes through proofpoint - Anything that doesn't resolve in O365 will route down to on-prem for address resolution Remaining legacy exchange 2010 for old mailboxes goes away in March - 2xMailbox and 1xCAS. Everything that was on it has already been migrated elsewhere or will be deleted outright (after legal retention is over in February). On-prem hybrid server is a single Exchange 2016 server. It is the sole SMTP outbound relay for copiers, apps, etc, and it routes all traffic outbound through proofpoint. I would like to get to a state where the only mail server I have on site is a simple IIS SMTP relay that routes out through an O365 mailbox.
|
|
#
?
Dec 7, 2017 03:06
|
|
|
devmd01 posted:So what are my next steps to get rid of our remaining on-prem exchange environment, without blowing up any existing exchange attributes? How does management work after you no longer have an exchange server on-prem? The nevergirls method is to simply turn off the exchange 2010 server and not decom it.
|
|
#
?
Dec 7, 2017 03:13
|
|
|
devmd01 posted:So what are my next steps to get rid of our remaining on-prem exchange environment, without blowing up any existing exchange attributes? How does management work after you no longer have an exchange server on-prem? If you’re syncing data with AADConnect you’re technically not supported without an on-prem exchange server, but that is supposedly going away in the next 3-4 months.
|
|
#
?
Dec 7, 2017 07:10
|
|
|
NevergirlsOFFICIAL posted:The nevergirls method is to simply turn off the exchange 2010 server and not decom it. e: Agrikk; what cert authority are you using? It's worth asking your cert provider if they do custom cert requests. At least with Digicert, I can request a specific common name in place of the *.domain.com, which I almost always do these days. After purchasing the wildcard cert years ago I was surprised to find that seemingly the majority of servers/software really don't like wildcard certs in their usual form. goobernoodles fucked around with this message at 19:34 on Dec 7, 2017 |
|
#
?
Dec 7, 2017 19:28
|
|
|
If you’re big enough shop that you need to do new-remotemailbox a lot and in batches then yeah keep on prem Server. If you’re just doing onesie-twosies like less than once a month just do it all in cloud.
|
|
#
?
Dec 7, 2017 19:38
|
|
|
goobernoodles posted:My understanding is that it's best practice to retain an on-prem Exchange server. Apparently you lose a lot of powershell functionality without the on-prem Exchange server, or so I've heard. I'm not sure how much truth there is since the one of the dudes this came from had a hard time grasping that I had a newer powershell module for AzureAD and that the commands he was sending me had been depreciated. We're also very early in our migration (10/260 or so) and I haven't yet started working on shifting user provisioning/update/term scripts to utilize O365 commands instead of on-prem. It's not just PowerShell you're losing, the GUI interface uses the same underlying services and you simply can't edit a lot of user attributes any more if you remove all Exchange servers from a domain where the users are still in an on-prem AD. If you have a hybrid deployment already, the limits of that show up fairly quickly if you commit to doing any and all management on users/mailboxes through the online shell (or https://outlook.office365.com/ecp). You can still edit on-prem objects through adsiedit or the attribute editor in dsa.msc though. NevergirlsOFFICIAL posted:If you’re big enough shop that you need to do new-remotemailbox a lot and in batches then yeah keep on prem Server. If you’re just doing onesie-twosies like less than once a month just do it all in cloud. This is also true I guess but I've never really found the place where it makes sense to do that. To keep an entire Exchange server on-prem for a really small company, maybe a 10-20 mailboxes (half of which aren't really used anymore) seems like overkill, I agree. But at small places without a lot of cutting edge/homebrew stuff going on, it's more often than not possible to move to the online suite entirely so you can eliminate the on-prem server that way. At smallish organizations where Exchange rarely needs actual work done on it, the combination of inexperience and management tools with little to no warning mechanisms is especially potent at making a bigger mess than would have been possible through the native Exchange PS. The smallest hybrid installation takes 1 core and 8 GB (maybe 4 even?) RAM, probably the only 'role' where you can get away with underprovisioning that if need be. It has no cluster to worry about, can be autopatched/rebooted with no effort, license is free(or rather, included with online licensing). I never regret having one around. The installation, maybe a firewall opening, adding 2 dns records and a 3rd party cert is <a day of work but doing it under stress of poo poo hitting a fan and needing one ASAP is awful. Then you have the larger shops, i.e. anywhere you might have an enterprise agreement or another type of licensing/support contract with MS. At those places you don't really have a choice because they're not going to support the artisanal editing of attributes, it's bothersome to do for many users + most managers want you to BEST PRACTICE any practice in sight (or at least run not too far afoul of the backup plan called MS Support while they're paying for it).
|
|
#
?
Dec 7, 2017 21:04
|
|
|
Old Binsby posted:It's not just PowerShell you're losing, the GUI interface uses the same underlying services and you simply can't edit a lot of user attributes any more if you remove all Exchange servers from a domain where the users are still in an on-prem AD. If you have a hybrid deployment already, the limits of that show up fairly quickly if you commit to doing any and all management on users/mailboxes through the online shell (or https://outlook.office365.com/ecp). You can still edit on-prem objects through adsiedit or the attribute editor in dsa.msc though. Slightly off topic, but I'm ironing out the details of a new MPSA agreement along with choosing what we'll carry SA over to a new Open Value agreement... I have almost enough Office ProPlus licenses that currently have SA, giving us access up to Office 2016. I've been planning on getting E3 licenses for computer users in place of renewing SA on our existing licenses, however that was primarily because I heard that we'd have to move to the O365 version of office. I was under the impression 2010 would simply not work, however, on a surface level it looks to work just fine. Is it worth sticking with on-prem/msi installed office paired with E1 licenses to save money, or is E3 still worth it to save against headaches? Anyone here have any experience with widespread use of non-O365 versions of office paired with hosted Exchange/O365? I haven't had enough time to dig into it yet into much detail.
|
|
#
?
Dec 8, 2017 01:22
|
|
|
It works fine but holy poo poo is licensing so much easier without needing to deal with Open agreements and SA renewals.
|
|
#
?
Dec 8, 2017 01:45
|
|
|
Thanks Ants posted:It works fine but holy poo poo is licensing so much easier without needing to deal with Open agreements and SA renewals.
|
|
#
?
Dec 8, 2017 19:09
|
|
|
|
| # ? Apr 19, 2024 18:08 |
|
|
For what it's worth, the compatibility of different clients is listed here: https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx Outlook 2010 is fine if it's up-to-date.
|
|
#
?
Dec 8, 2017 19:37
|
|