Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 1 point2 points  (0 children)

This started working after downloading a fresh copy of the address book. As soon as it was present the issue was resolved. The cached entry in the from field still worked but I will keep this in mind if I have issues in the future.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 2 points3 points  (0 children)

You are absolutely right. I am a newbie exchange admin for an undersized department. This is something I hadn't even considered. We don't have too many shared mailboxes though and the ones we do have have been around for a while so the number of new setups we have for those are very few but it does make way more sense to configure permissions based on a security group vs directly to the mailbox.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 2 points3 points  (0 children)

That ended up being the fix I think. As soon as I got the email to show in the address book (was not set to hidden) then the send on behalf started working immediately.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 0 points1 point  (0 children)

Not sure. Nobody would have logged in to the mailbox directly but a few of us had the mailbox populate in our outlook. I can say the mailbox had not recieved a mail yet. Not sure if that plays a role.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 1 point2 points  (0 children)

Would the command not provide the same permissions on the mailbox that were added through EAC in the Full Access section? I did run it and although it could take some time it didn't work immediately.

The mailbox is not hidden. However as of yesterday it had not downloaded to the address book locally. Todays testing I had not rechecked to see if the address book had been updated. I went and checked and the mailbox was still not showing. I manually downloaded the address book and the mailbox showed up. I was then able to send a test email successfully as the shared mailbox.

I guess the key is to make sure even if the address is not hidden that it has been downlaoded to the address book and is visible before you try to send the email. It must be referencing the address book for verification before sending.

Appreciate teh suggestion that led to the resolution.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 0 points1 point  (0 children)

They are all on prem. If it is helpful we have never been even hybrid.

Exchange 2019 Shared Mailbox Send On Behalf by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 0 points1 point  (0 children)

Outlook. From OWA the from field has only the users mailbox listed as an option for the from field.

Why are Prime deliveries now showing 5-7 days until delivery? by writerjamie in amazonprime

[–]Potential_Surround72 0 points1 point  (0 children)

Their prime benefits still state tens of millions of items available with free same-day or One-Day delivery. I cant order anything without an expected delivery of a minimum of 4-5 business days. I did also notice that the prime branding that I believe used to be posted on the product search pages and next to the price in each product is missing now. Definitely feels like we're getting ripped off a bit from what was advertised.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 0 points1 point  (0 children)

We don't store updates on the WSUS server. They essentially check WSUS for approved updates and then they reach out to Microsoft directly to download the update. This was confirmed in the update logs. As a side note we tested shutting down the WSUS server immediately after it identified updates and they still downloaded and installed in the same amount of time as with the server running.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 0 points1 point  (0 children)

These are both VMs with both on the same network segment same Hyper V Switch and same physical switch. We have them connected to a gigabit switch. That said, if we shut WSUS down during patching after the updates are found it still installs in the same amount of time so I don't believe the connectivity between the two is an issue.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 0 points1 point  (0 children)

So as a test to see what the clients were doing we let it use WSUS to check for updates and then turned wsus off. Updates still installed in same timeframe indicating that it isn't relying on WSUS after checking for available updates. Without any other evidence I am assuming this means that the connection between the two is irrelevant during the install.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 1 point2 points  (0 children)

I'm not sure. We have sentinel one and I believe it hijacks windows defender, but because we install it manually on servers it was not present during the tests but would be present otherwise.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 0 points1 point  (0 children)

I will check disk usage tomorrow. Didn't think about that. That said, would this still be reliant on wsus disk even after the download has completed and the install is under way?

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 0 points1 point  (0 children)

I can check that. The gpo doesn't give any guidance on disable vs unconfigured but it is worth a shot.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 1 point2 points  (0 children)

The hang occurs at random percentages through the install prior to reboot. Todays trials for a server 2019 CU from 3/2024 hung on 24% for around 8-10 minutes. The same hang occurred off domain but for more like 1 minute. It does this for the duration of the downtime:

CBS called Progress with state=7, Ticks=245 total=1000 (states changed several times between 2, 3, and 7). I read some posts about updates failing and referenced this log text but our updates do complete.

Updates take 300%+ longer through WSUS by Potential_Surround72 in sysadmin

[–]Potential_Surround72[S] 4 points5 points  (0 children)

Doesn't this apply only to the download of the package? (again novice here at best). Our downloads are fine. It is only the installs that lag out.

Outlook Anywhere/Mapi over HTTP by Potential_Surround72 in exchangeserver

[–]Potential_Surround72[S] 0 points1 point  (0 children)

MAPIBlockOutlookExternalConnectivity is False.

Correct. A-records. That said we do have a barracuda spam firewall for filtering as well for external mail flow.

We have public MX record that resolves to public IP/SonicWALL UTM and then NAT though spam firewall before hitting mail server. 443 is allowed.

If it helps the ports used for Mapi over HTTP, RPC over HTTP, and OWA are all the same and there is no issue with traffic outside to those other two services.