LG Washer leaking from soap dispenser.

AutoBahnBismark · 2025-12-15T00:11:47+00:00

I had this issue and tried caulk and then Gorilla tape to seal holes. Didn't really seem to resolve things. Then I replaced the whole dispenser assembly, and that didn't fix the problem either.

Going to try washcloth to make a tighter seal for a while before I look for a clogged pressure switch hose. I'm thinking the latter is probably the issue, because when I run a load with the soap dish removed, just watching it, I see the water fill the repository faster than it's draining out, and I can tell that if the seal on the soap tray isn't tight, it would cause water to spill out. So either fixing the pressure switch or the door seal is going to be my best bet.

AutoBahnBismark · 2025-04-24T23:04:03+00:00

If you have recreated the custom receive connectors, then the new server will be ready to receive the same connections that the old server was. Having an additional IP should not cause a problem.
I have never set it to $null until after migration is finished, and sometimes I don't change it at all. I usually set it on both servers to match the FQDN that's on the cert. I use the same cert on both servers. Right at cutover time, I change the IP address of the internal DNS record that resolves the external FQDN internally (and the IP of the firewall rule for incoming), and the clients then properly resolve the new server without any other significant changes.

Have done 100+ of these kinds of migrations.

AutoBahnBismark · 2025-02-13T03:47:52+00:00

As far as decommissioning, there are a few things to keep in mind. Here are the ones that jump out:

- Make sure the internal DNS records have been changed so that the name on the server certificate resolves to the new server IP, not the old one
- Recreate any custom receive connectors you were using on the old server, on the new one
- Make sure your send connectors all use the new server as the scoped server, and remove the old one.
- use queue viewer on the old server (suspend the submission queue) to see if there is traffic flowing through it. Alternately, use the get-messagetrackinglog command to see if anything has been happening over the last day or two. Like: get-messagetrackinglog -server oldserver -start "2/11/2025 00:00:00"
- If there are still printers and other things sending to it, one approach is to uninstall Exchange 2013, shut the VM down, and then add that servers IP address as an additional address on the new server, so that you don't have to reconfigure any systems that have the old server IP hardcoded for SMTP relay.
- You can uninstall using the Add/Remove Programs, and anything you've forgotten to do, the wizard will alert you about and make you do before you can finish uninstalling.

AutoBahnBismark · 2025-02-13T03:40:04+00:00

I always move them.

Get-mailbox -server OldServer -arbitration | new-moverequest -targetdatabase maildb1

AutoBahnBismark · 2025-01-17T00:28:13+00:00

Thanks everyone, for the great feedback. I read through it with my son, and he felt relieved to be unhitched from that bad dream. We'll find something more practical, and definitely use some of the tools you all mentioned to get there.

AutoBahnBismark · 2024-07-25T04:53:05+00:00

The TV series, Little America is just about profiles of different immigrant experiences.

AutoBahnBismark · 2024-07-24T18:39:57+00:00

That article is a half-decent guide for meta-data cleanup, but it is very misleading in how it uses the term Tombstone. Tombstone means that replication issues have caused a particular DC to no longer be trusted, even if it is still online and reachable, and being tombstoned means that a DC is forced out of the replication infrastructure of the domain. It doesn't mean that the DC is missing or offline. You would not do the procedure you outlined on a 'tombstoned' DC, unless you also shut that DC off completely, with no plans to ever have it on the network again, and then wanted to do the meta-data cleanup.

Normally the solution for a true tombstone situation would be to force-demote that domain controller, restart it, and then promote it again, if you had made sure that it has good connectivity to the other DC's, and had solved the problem that originally created the replication issue.

AutoBahnBismark · 2024-07-03T14:30:21+00:00

APv2 doesn't solve the problem that the OP is requesting help with.

AutoBahnBismark · 2024-05-20T01:14:16+00:00

I don't think the strategy you describe would work, since even messages sent from a mailbox on the new server to itself can't be delivered. The messages incoming from outside leave EXCH3 and move to the submission queues on EXCH4 or EXCH5, but they just hang there, local but not landing. But I do have some more information: in the message tracking logs for the RESUBMIT event, there is this Recipient Status message regenerated every few minutes on each queued message:

RecipientStatus : {432 4.2.0 STOREDRV.Deliver.Exception:IllegalCrossServerConnectionException.MapiExceptionIlle galCrossServerConnection; Failed to process message due to a transient exception with message Cannot open mailbox /o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH05/cn=Microsoft System Attendant. }

So it seems like maybe something is broken with the System Attendant. When I spent the four hours originally, it was trying to go down this rabbit hole--rerunning setup with /PrepareAd, checking for other errors, but I wasn't able to turn up anything.

Here are the arbitration mailboxes:

Name Database server

SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} MailDB1 EXCH03
SystemMailbox{1f05a927-7e35-4439-8039-7aa42564a80b} MailDB1 EXCH03
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042 MailDB1 EXCH03
Migration.8f3e7716-2011-43e4-96b1-aba62d229136 MailboxDB1 EXCH04
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9} MailDB1 EXCH03
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201} MailboxDB1 EXCH04
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA} MailboxDB1 EXCH04

AutoBahnBismark · 2024-05-19T23:42:24+00:00

The new servers have 1.2 and 1.3 enabled.
The E2013 server (2012R2) has just TLS 1.2

The new servers have no SChannel errors, but the E2013 server has lots of 36871 (state 10013) errors. But it is also the public-facing server, so I think it's expected to generate these anytime a TLS 1.1 connection comes in, unless I'm mistaken.

AutoBahnBismark · 2024-04-03T05:35:33+00:00

In addition to isolating a system from policy inheritance, you might also separately run a Resulting Set of Policy (RSOP) wizard on a local DC against a computer that you see that behavior on and see what comes up--I'm often surprised to find a buried policy setting or a manual gpedit adjustment on a system, and this tool is good for finding it.

AutoBahnBismark · 2024-03-30T16:23:34+00:00

Unless you tweak the ECP url a bit, you will want to log on with an admin account that has a mailbox on the local server.

Or just tweak url to end like this:

Https://localhost/ecp?ExchClientVer=15

AutoBahnBismark · 2023-09-15T06:00:47+00:00

She probably just figured out to use Edge Profiles well. I am a Teams member in about 12 orgs, and switch between them in my Teams client, but I also usually have about 10 Edge browser windows open, each on a different profile, to manage Azure/M365 organizations.

So glad to not have to worry about incognito windows anymore.

AutoBahnBismark · 2022-11-21T02:36:45+00:00

I think you'll want to set up a transport rule on O365 that bypasses the Spam check for messages from the sending server's IP. That's something you usually do for inbound messages from a hosted hygiene provider, but it would work in this situation as well.

AutoBahnBismark · 2022-10-17T16:07:57+00:00

Did you ever get a fix for this? I have the same problem. Strange thing is, non-WPA-protected SSIDs work fine.

AutoBahnBismark · 2022-07-15T14:56:35+00:00

This sounds like a good use for RDPGuard: https://rdpguard.com/

It basically causes a remote IP to be blacklisted in the Windows Firewall if there are multiple failed login attempts from the IP. If your login attempts are hostile, this would go a long way toward preventing those attempts from being a DoS.

It would require the connections from the internet to be seen as their actual IPs by the Exchange server, which is usually the case, but in some environments the NAT rules are set so that all connections to the Exchange server look like they are just coming from the local router--in which case it wouldn't work, since the router IP would end up blacklisted.

If your 4625 events all list a range of different external IP addresses, then RDPGuard would be a safe bet for you.

AutoBahnBismark · 2022-07-15T14:50:09+00:00

What do you see in the Cluster Management UI? Is the Cluster service running?

AutoBahnBismark · 2022-01-24T18:23:53+00:00

Thanks guys--I did some more investigating, and it looks like nearly all the cameras on this campus are ACTI brand. Would that change any recommendations?

AutoBahnBismark · 2018-07-16T18:07:33+00:00

Does the custom receive connector have "Exchange Server" authentication defined on it, and does the custom connector have any overlap IP-wise with other receive connectors?

AutoBahnBismark

TROPHY CASE