User Profile
christiaan-nl
Brass Contributor
Joined 5 years ago
User Widgets
Recent Discussions
Re: Exchange Server was exploit and used to send spam email
We closed the case internally as we see this as a new form of spam that tweaked known algo's. Now all mail messages are picked up by antispam, so probably they found a new way to get passed them. We performed checks on various systemens and see no reason to continue the research for now. However, we will do extra monitoring on abnormal mail activity.4KViews0likes0CommentsRe: Exchange Server was exploit and used to send spam email
Hello Don, We are investiging similar messages and messages primarily for non existing domains in our environments. In our case mostly for .com.br and .com.ar domains, although totally not relevant for any of our organizations. We don’t expect any of our organizations is compromised and so far we trace it back to a new form of spoofing or tricking spamfilters. All out Exchange farms are behind different isolated relay solutions. Mails are related to payments and bitcoin frauds. Also classical “we see what you are doing online” messages. So far we see it has stopped at dec4 22:10 EU time. I will update here if we find some interesting details that are worth sharing. In any case I suggest you to send an internal message that users should be careful. Kind regards, Christiaan4KViews0likes1CommentRe: OWA Attachments after CVE
CTechCamen Hello! I am just being reported that we have the same issue in one of our managed environments. We run multiple Exchange environments. One of this is experiencing the same issue. On the Exchange Team Blog I wrote a reply that we have not had any issues, I had to update it with this one. We have configured Download Domains way back, it all worked fine. Somehow, just after the march patch attachments are not working anymore. Either embedded imaged and attachments like zip files. They result in the error shown below. This issue is now just in one of our environments, not all. I am still investigating. The issue is weird, because we run other environments, exact same setup, OS, patch level, load balancer, etc. Though I don't think Download Domains is the issue here, looks like something is broken in OWA on this environment. Will do basic tests first and if necessary recreate the OWA virtual directory. Issue doesn't look server specific btw. Eventlog doesnt' throw any error or something. Usually this shows something about page errors, etc. I will update you here on our findings, but please continue your own research as well. Update as of now: I have deconfigured the CVE-1730 mitigation (Download Domain Config) in one of our organizations having the issue. We have only disabled the Download Domains setting at org level. Then restarted IIS on earch server. It now works again. 1 > Disable Download Domains on Organization Level PS> Set-OrganizationConfig -EnableDownloadDomains $false Optional: 2 > Set the server configurations back to default (Run this against every Exchange Server in your org) PS> Set-OwaVirtualDirectory -Identity "owa (default Web site)" -ExternalDownloadHostName $null PS> Set-OwaVirtualDirectory -Identity "owa (default Web site)" -InternalDownloadHostName $null Verify with: Get-OwaVirtualDirectory -Server <ServerName> | fl *downloadhostname* Get-OrganizationConfig | fl *download* 3 > Restart IIS / Reboot Server (Maybe first disable server in load balancer the descent way, depending on your config). Next We will work on this issue later on. We set the risk of this CVE to low in our organization as we follow the exploitation indicator for this specific one. We leave it enabled on all other organizations.4.8KViews0likes0CommentsResolving Exchange Server IIS 500 - Maintenance Error
Hi All, This is my first post here, ment as advice / troubleshoot tips for Exchange admins. I see regularly Exchange admins having trouble with IIS 500 page errors. This topic is not rather a question, but some information I would like to share with admins that run into an IIS500 Error (reason: Maintenance) on Exchange OWA and ECP after installing .NET Updates. The page of ECP (and OWA) looks like the follow page below. Please note that IIS 500 can also be triggered by other errors, this is for specific the situation written below. If you have recreated the virtual directories, you find out that the problem is still there. The example here is based on Exchange 2019 / Windows Server 2019, but I have also seen this behavior on Exchange Server 2016 and Exchange Server 2013 on Windows Server 2016 and 2012R2. Rule one: Give Exchange servers some time booting up, don't try to immediately logon to ECP/OWA when the logon screen beach appears on the console. Check the CPU up-time, and I recommend waiting at least wait for 5 to 10 minutes uptime (CPU time) and verify the server CPU usage has normalized. IIS 500 common error checks Although IIS 500 is quite a common error, there are some occasions where you should figure out if you have installed Windows / .NET Updates on the server you are working on. Please examine the server eventlog for details in the “Windows Logs > Setup” section. If so? You should first verify that all Exchange Services are running correctly that have the startup type to start automatically. In environments we manager we regularly see the following services not starting after a reboot of the server: MS Exchange Replication (note: also for single server setups) MS Exchange Transport Log Search. MS Exchange Compliance Audit. Some others, but most are running OK. Note: When rebooting your system, the services not starting can vary. You will also find: Eventlog Application Error Exchange Compliance Audit because “Mailbox database is not available”. Eventlog Application Error ActiveSync cannot open mailboxes. Other Exchange errors referring that it is unable to do some “things”. Server memory usage is lower than normal after a reboot. What should you do? First, start the Exchange Services that aren’t running and have startup type set to automatically. Start with back-end services like MS Exchange Replication and give it some time and lastly start services that are for log searching or auditing. When observing your performance monitor you will probably see a surge in resource usage. In the Eventlog > Application you will see some Exchange things to come to life again. After a few minutes, when you login to ECP you will see the environment again (note: the first time someone logs in to a virtual directory the web-pool needs to start, this might take a few seconds). Restarted the server and it’s broken again! If you restart the server again, you will probably run into the same situation again. Why? The root cause is not known to me, but it has to do something with .Net Framework updates. What you need to do is basically waiting. So, don’t reboot the server if you have your pages working again by starting the services, etc. Rebooted the server? You can do the actions written above again. .Net Optimization Proces For it to permanently work after reboots you have to wait for a process to start working on the .Net optimization. When the server is “idle”, usually 20-30 minutes after booting up the process “.Net Optimization Task” starts running on your Exchange server. This usually takes up to 20-40 minutes. When it’s done you will see most of the time (not always) notifications in eventlog: Application > .NET Runtime Optimization Service > EventID 1130. .NET Runtime Optimization Service (4.0.30319.0) - Installed from repository: mscorlib When the task is completed and you restart your server again, it should be running fine again. You don’t have to reboot the server If you have started the services manually. The key is they don’t want to start automatically unless the “.Net Optimization Task” has done it’s thing. What actually happens, I don’t know, maybe some of the Exchange Team members can give an answer, but this is what I’ve found out in many environments (test production, etc). It doesn’t matter if you install updates with Antimalware software switched on or off. I hope this will help some users having trouble and starting to fix thing’s that actually aren’t broken, but just need some special attention.9.6KViews0likes0Comments
Recent Blog Articles
No content to show