If your company has email, odds are you also have Microsoft Exchange. Join guest Phoummala Schmitt (@ExchangeGoddess) along with SolarWinds Head Geeks Patrick Hubbard and Leon Adato as they dig deep into Exchange monitoring. They will review best practices when using Server & Application Monitor's AppInsight™ for Exchange feature, and highlight issues when moving Exchange to a cloud or hybrid cloud configuration. They will share tricks and traps with Office 365, and help solve a common head-scratcher that Exchange admins run into when migrating users.
Episode Transcript
What are you doing, Leon? Well, I'm working on this test alert. It's a little rough, but I sending it all to email, so it's not like it's any big deal, anyway. I mean, it's a thousand emails. Send one more email storm and I'll accessorize you. Hi Phoummala. Hi. Welcome to the show. Thank you for having me. You are just a teeny bit passionate about making sure that Exchange is running well. Well, my Twitter handle is ExchangeGoddess. That's true. I'll tell you what, let's spin this entire episode and dig into that. I'm pretty sure that all you guys out there would really like to know a lot more about Exchange, and certainly your expertise is going to be really, really great. Leon, why don't you get us started? Sure. Welcome to SolarWinds Lab. I'm actually not sure I'm going to survive this whole episode. Seriously? I'm Phoummala Schmitt. And I'm Patrick Hubbard. So, Phoummala, you have a pretty strong following here at SolarWinds. Certainly, our folks out on our THWACK community talk about you. You're ExchangeGoddess on Twitter, and you're a co-host of Current Status out on, it's a Google Hangout, along with Theresa Miller and Melissa Palmer. Correct. Why don't you give a little bit of bio for maybe some of the folks that don't know you? Well, I'm Phoummala Schmitt and I am an Exchange admin. I've been doing it for about 12, 13 years now. I currently run an enterprise of over 10,000 users, but I've managed enterprises up to 30,000 mailboxes, and in a global environment with multiple languages: Russian, Polish, Spanish, Portuguese. Localized Exchange troubleshooting, no problem. Oh never, no, a breeze. Great. Well, we're really glad to have you here, but I know there's probably some people out there who are wondering why, since you're so email and Exchange-focused, why you'd come on a show that's typically really centered on monitoring. Two reasons come to mind. First, monitoring solutions, whether they're homegrown or they're full-blown applications like SolarWinds are frequently the culprit of email storms. Yeah, just a little bit. Yeah, people don't think nothing of it when they put a distribution list or when they fill out that "To" field. What can happen when lots of emails get sent out, like thousands, especially with monitoring applications, that can actually choke up your mail server? To all IT, it's fine. Oh, everybody in IT. Actually, to all users. Second, rumor has it that you guys have a pretty kick-ass Exchange monitoring tool and I wanted to check it out. Okay, well fair enough. Where would you like to start? Well I don't really have anything else to do. I'm just going to stand right here. Great, well, how about, "sudo, make me a sandwich." I will make you a sandgowich. It never gets old. All right, so are we starting with monitoring or the lecture? Let's start off with the monitoring and we can work our way towards the lecture. Fair enough. So what we're looking at here, where we're starting is AppInsight for Exchange, just our Microsoft Exchange monitoring, sort of holistic tool. And what I'm curious about is, from a health standpoint, where is your eye drawn as an Exchange admin? What are the things you think are especially interesting? The first thing I see right away is the active alerts. That pretty much is kind of your overall summary of your diag environment. Sure. You know, it tells you if your active manager's up or down. If you see any reds here, it's definitely a key indication that you need to take a look at your environment and see what's going on. So all these status checks? Yes. Okay. It's that overall summary of like, okay, I'm good. Okay. It's that first pass. Great. And then if we go down to replication, if we scroll down, which is at the bottom. So replication is key, especially when you have a diag like this. It basically tells you how your database copies are acting. You know, your copy queue length, your replay queue length. If you see these numbers creep up, that's an indication something is going on with your diag, whether you have any type of network latency going on, or even you have a database down and you don't know it. There could be something going on here. So if the numbers are on the far right, you definitely want to start taking a look. Sometimes you may see peaks. Let's say you have a network blip. You may see your copying... Like we have here a little bit. Yep, yep. There's definitely activity on here, but it's not spiked and it's not steadily creeping up on here. Yeah, it's not consistent. It's normal to see some peaks here and there. Just like with any server, you're going to see the peaks. You're going to have your valleys and that's okay. But if you have a flat line, that's not good. Ah, so that's another thing for everyone to keep in mind, is that some activity is actually better, is best, that no activity does not mean that your rock solid. It could mean that either you're not collecting a statistic or lights are on, but nobody's home. Yes, if it's just completely flat and there's nothing there, then okay, let's take a peak at that. So a little bit of up, you want some valleys. Got it. And then the storage one is also good to look at a high level. These are your IO writes. If you start to see a lot of high writes and reads, some flat lining, that's an indication that you might have some disk issues. Okay. I've seen issues where one or two disks go bad on the server, and you're going to see an impact on the overall server. You know, if it loses one or two, especially on your older generation disk. Okay, so we were also, moving back up to the top here, we were looking at the database, the database size and space usage. Yes. When we were preparing for this and you were pretty interested in what the stories that this had to tell. So, with database sizes, this is a really good key indicator of one, your growth patterns, as well as your, not only growth, but the health of your databases and how much storage you have. So, you've got a database here with seven gigs, and you can see, okay, it's using 42%. Now, if you start seeing patterns that it's growing, obviously there's something going on. Either you have a lot of growth or someone is sending a lot of mail. There's just something going on. If you drill deep into that database, another key indication to look at is, you want to look at your log LUNs and volumes. If you notice that your log LUNs, your transaction log LUNs volumes, are high and there's very little space left, then something is going on because your logs aren't truncating. So it could be your backup software isn't truncating your logs. I've actually had a couple incidents of my own managing Exchange where my log volumes, log LUNs, were growing. And I noticed like, something's off here, it's not, one database log would be normal and the other, I had like 2% left. So obviously I'm like, there's something going on here. So I jump on, I realize wow, my snapshots; my snapshot software wasn't truncating my logs correctly. Ah. So there was something going on with the snapshot utility. By catching that early enough, I was able to prevent a database dismount on the passive. Now, if you have passives, that's good, because it's only going to take the passive out first. But then eventually it will take your active. So, that's why you monitor, that's why you look at these, so you don't go to that actual active copy. Right, and that's something else to point out, is that monitoring, especially in an active/passive environment or any sort of load-balanced or high-availability environment, you do need to monitor the passive leg and alert on it. Maybe not a critical alert, maybe it's going to be just a, hey, you know today you need to get to it. That counts for backup circuits, it counts for backup paths on your SAN drives, and it counts for backup servers for Exchange because otherwise what happens is either people take it out for maintenance and forget to bring it back up, I've see it happen a lot. Or, it's down or impacted like you just said, but nobody really has responded to it because it's not being monitored effectively. So, those are some things to definitely keep in mind. Going back to the main page, Because this is actually the Mailbox1 page, so there's some other statistics here that-- So if we can go back here and look at your database health, this one, database copy. This is the health of your copies. So you've got Mailbox1 and you can see here that you have multiple copies and it shows you what's mounted. Mounted, that's the one that's active. And the other ones that say healthy, those are your passive copies, or what Exchange is considering your passive copy. So let's say, normally, you would have copy number three be mounted, and you come in, you notice, oh wait, number one is active. What's going on? So, obviously something happened that evening where it switched on which is mounted and which isn't. I've personally had that happen to me as well. You know, network blips, in the middle of the night, wake up and go, oh wow, that's interesting. I'm running out in my colo facility right now. But you know, still running, nothing was impacted. You know, I just flipped it back over to where I wanted it to be, but based on monitoring, you could see that okay, my active is not where I really, you know, it's not where I want it to be. And that speaks to another piece, which is that monitoring will give you the data, but you still have to have an awareness of the environment. You have to know, in your example, that mailbox three is where to be mounted, and it's not. So you still have to be aware of that. Now, alerting can take of that. You can put the logic in there, but you, the operator, or you, the monitoring engineer in combination with the Exchange admins are going to have to use the knowledge of the environment to pull that together. Oh yeah, you definitely have to understand. If you have a diag, you have to understand your environment. You need to understand where the databases are supposed to be at and where they're not supposed to be at. Because if you're just looking at this, any Joe Schmoe could be like, oh yeah, it looks, everything's green. It's all mounted, healthy, everything looks fine. But, if I were to come in and I would look at this and go, you know what, something's off. Something doesn't look right. And I've done that, you know. I've had people say, oh every looks—Exchange is fine. No, it's not, something's off. Right. So, you do need to understand. Excellent. And then we also have "Users by Mailbox Size." Okay. Do we want to talk about that a little bit? Yeah, let's talk about some users. So, you know, if you're going to do any migrations, or you're monitoring just storage of user mailboxes, if you have quotas, this is also a good graph to look at, especially if you have storage limitations. You could see, okay, I've got, you know, Charlene, Ms. Foley is really up there, both in usage in terms of megabytes and also in terms of the quota size. Yeah. In some organizations, they still have storage quotas, some don't. They've removed that. But for most, there are still storage quotas because storage is not an infinite pit or pool of magical… Oh come on, it is, it is! It's this beautiful, happy, I can have as much as I want, right? That's what the storage admin says, right, or that's what he dreams. And Exchange is notorious for just eating up storage because it doesn't have single instance storage anymore. So we just gobble up storage, but storage is cheap, right? Right, right, exactly. Storage is cheap. And one other area that's always a lot of fun is the ‘Users by Messages Sent.’ You know we want to keep track of that because it may be small messages that are being sent out, but a high volume of them. Yes, with this one, this one's a tricky one. I've used this for auditing purposes as well, too. I've had requests from Legal; they want to know how much mail a user is sending to see if it's really legitimate. But also, this helps you track how much traffic are you actually generating, so it's good to look at that. Obviously, Critical Processes and Services is definitely always, you want to make sure your services are running. If any of these are down, most likely, Exchange isn't going to be running very good. Or at all. Yeah, so if the Cluster Service is red, you don't have Exchange anymore. The Exchange Active Directory Topology service, if that's down, you don't have Exchange anymore. Right. So, you'll probably have a lot of tickets in the help desk queue right now, if those are down. Right, and although it's all clean here at the moment, how much CPU it's using, how much physical and virtual memory and the IOPS, IO operations per second, are all things to keep track of. Yes, and this is where the backpressure. Okay, so tell us a little bit about that backpressure. Backpressure is just the built-in monitoring within Exchange. It's like that self-aware, self-monitoring mechanism that Exchange has. And there's different thresholds. There's normal, there's medium, and there's high. And it monitors your storage, the memory, and also the message queues. So when it reaches a certain threshold, Exchange will send off warnings and then once it reaches a high, it'll actually do certain actions, you know, stop sending mail and stop receiving mail. It can dismount databases. There's certain actions, and actually if you go to the TechNet site, there is a very, very long list of actions that it can do. I don't have them all memorized. Pretty much, it just stops working. If backpressure is in the high category, Exchange is very smart. It says, you know what; I don't want to work anymore. It basically shuts itself off and this section here is kind of your visual of... For that. Yeah. And, the point here also is that backpressure is going to take massive evasive maneuvers. It's going to shut down the database rather than corrupt the data, which is a whole weekend's worth of pulling data back off tape or from a remote site or whatever. You don't want to have to be dealing with that so backpressure shuts it off. But this will let you know before backpressure kicks in, so you can adjust things before you get to that point. And that's why the monitoring is there, just because back pressure's there, you don't want to depend on it because it's not a fail-safe. It's just kind of like, I'm going to stop doing this. But by that time, have you already had a negative impact on your database or on your sever? So monitoring these key points kind of prevents major issues. Because once you've reached high, it's usually not good once you've gotten to the high point. When you've reached medium, it's kind of like, hey, I need to look at this. I need to prevent myself from getting high. And of course, all the monitoring data feeds right into the alert engine, which means that once you have a solid sense of where things are and what's out of spec, then you can create robust queries that take all that logic into account for real alerting thresholds. And that's where we need to have a little sit down. Okay. And discuss some best practices when you're setting up test alerts and sending to production emails. Okay. So when you're setting up alerts with applications or a monitoring software, you really have to be cautious in how you're doing it and work with your Exchange admins. Because if you do it at the wrong time, you can choke up your hub transport queues. One of the best things that I like to tell people is, when you are setting up your alerts, limit to how many people you're sending it to and limit the times that you're sending the alerts. So let's say if you're going to be testing, or you're doing an upgrade, you may want to turn those alerts off, but especially if it's any type of testing, because you're going to generate traffic. And if you are going to be testing, try to do it in the evenings, low business critical times. Never want to do it eight o'clock in the morning or at five o'clock, when everyone's trying to get emails out the door. Right. So like 11 o'clock, midnight. But, you know, if you're a global company, those times may not work. So you really have to look at your business and see what time frames are better for the environment and that's where you have to talk to your Exchange admins and say, okay, we're going to be doing some testing, and I have some alerts set up. What is the best time frame? Right. And we understand, as Exchange admins, you are going to do this because alerts via email, it's easy. Everybody wants to look at their inbox. They wake up at two o'clock in the morning or at seven, and the first thing they do is you know, oh, I have all these alerts, something's happening. So it's convenient. Nobody wants to wait or dig through log files. It's just so much more convenient, so we understand, but we also want to work with you and give you the best tips for doing it. Sure, and that's talking about testing. Now, there's a few things as a monitoring engineer who's been around the block a couple of times that I just want to mention, as well, which is email may not be the best way to test alerts. I know it's the first thing that we think of. It's right there and it's handy. But in reality, there are other ways that SolarWinds and other NMSs can send out messages, especially in that test mode. You can send a syslog message to a syslog server, whether you're using a Linux open source solution or a Kiwi Syslog Server, which is a very effective way. You can send those messages. You get the entire message body just like you would in an email, but you're not impacting the Exchange environment. You can write to log files. Yes, you're right, sometimes digging through them is hard, but we're talking about testing alerts, so tailing a log file isn't such a big deal. You can also write to the Windows event log, which may be easier for some people to look at or look at remotely as you go. So, please when you're thinking about testing new monitoring alerts, don't just go straight for the email option. The other thing is that with the email, you have to hit F9 and you're waiting for it to come back and things. Whereas those other options that I mentioned are actually much more immediate from the testing standpoint. So just something to keep in mind. Now that's when you're testing a new alert, but how about production? When I'm thinking about setting up a real alert for a real application in production, and I know that the system's going to go down. There will be impact. What are the things I should be keeping in mind? For production, that's a difficult question because it's going to happen that's why that alert is there to begin with in the first place. In the event that your production environment does go down, you're alerted via email. One key I tell everybody: don't include log files. That's just horrible. Sometimes those log files can be huge, megs, megs. We don't want that in your mailbox, especially if you're sending to a distribution group of maybe 20 admins or even just five. Without single instance storage anymore, you've just increased your storage needs because of that log file. Also, depending on how big that log file, it's going to slow up your email for everybody else and yourself including, especially if you want to look at it on your mobile phone. But other than that, for production, you can't really get away from it. I mean, that's the whole point of the alert. It's going to be there. We understand it. As Exchange admins, we have ways to address the situation at the time, so when it happens, we can catch it early enough, we can stop the queues, create some transport rules and block the email from some more expansion. We actually talked about that. We did a webinar just a couple of hours ago and we talked about some of the tools, so you might want to look that up on solarwinds.com, look up the webinar that Phoummala and I did on Exchange troubleshooting because we've got some PowerShell scripts for that. But meanwhile, one question that comes up a lot for me is whether it's better to have to send a notification to a distribution group, to a single mailbox, or to send it to a number of people. What are the pros and cons to that? It really depends on your setup. You could do it both ways. If you have a shared mailbox, there's an added benefit where it's just going to one mailbox and everybody else is connecting into it and looking at the alerts. The downside is it can be kind of lazy. I am lazy. I have access to a shared mailbox, that's our team mailbox. And I have to admit, I don't always look in it like, every hour, maybe once or twice a day, so if there's an alert that's being sent there, I may not catch it until the next time I check. Ah. So, you know, that's a drawback. Also, people like to look at their phones for email. And shared mailboxes, depending on your mobile device management software, you may only have access to one mailbox. True. So you're not going to see the alerts unless you're forwarding that email to your inbox, which then is causing more traffic. So it just really depends. And then if you send it to a distribution list, the pros are everybody's getting it, everybody's alerted. The con, everyone's getting it. That's true, too. Everybody's receiving it. Yeah, and depending on how many people are on that list, it could be five, it could be 20. And if you have log files in there, you're just adding on that storage. So it honestly just really depends on your individual setup and I know that's, you know, that is the answer that everyone says. Right. It just depends. So, I'm going to also add, again, from the monitoring engineer standpoint, that as we said earlier, email is easy, it's fast, it's the first thing we think of, don't do it. [Laughing] Really, don't do it. Don't send your notifications to email. First and foremost, you should be sending it to a ticket system. Don't have ticket system? We're SolarWinds, we're here to help. We have one. But you should if you have one, send it there. Ticket systems have tracking, escalation, knowledge base, all those things that make a monitoring notification and its follow up much more robust. You know, email, did they get it, didn't they get it? Did they all get it, did they half get it? You don't know. So, just reconsider that. First of all, it'll take a lot of pressure off of the harried Exchange admin. Well... As well as, okay, it'll take some. It will. It depends. If you're sending it to a ticketing system, still email. Well, okay if you're using an API, Yeah. Then it's not. If it's going by email, then you're right. But it's one email to open a ticket, but you're right. It's still going to... Unless it's 15,000 emails. Okay, so stipulated. Okay, we got it. But yes, yeah, there's different ways of doing it and it's best to work with your Exchange team, the messaging team, also, probably, your help desk administrators, the application administrators and see what is the best way to handle issues like that when they come in. You know, writing to a log file or sending an email, because there's different ways of doing it. Excellent. Okay, so the next thing I want to get your take on is Exchange in the hybrid cloud, it's very big news, and also your opinion about Office 365. Oh yes, unicorns. So Exchange in the cloud, technically is really not supported. So, if you wanted to run all your own Exchange environment in AWS, Microsoft does not support that. But, Microsoft just recently announced, I want to say last week or a couple weeks ago, that Exchange, sort of-ish ad hoc, can be run in Azure. Go figure. What a surprise. Yeah, surprise! And Office 365, I actually really love it. I think it's great for companies that are small. Running Exchange is a full-time job. And with Office 365, that takes that management of a server away and you could just focus on creating mailboxes and creating your policies. Even for large organizations, you can off-load some of that server management. Once you get into the specialty industries, like healthcare, also energy, you have to be a little bit more probably specific. There's a lot of regulations. So, there's more caution there. But, doesn't mean that they can't do it. You just have to be cautious in how the security is. But, so you know, I'm for the cloud because I love unicorns. Okay, good. Just don't put it on Amazon. Okay, so as far as migrating your Exchange environment to Office 365, which is again, the darling right now, what are some of the things that people should be thinking about with that regard? Well, migrating Office 365 isn't a one-click button. I'm going to be there tomorrow. Really? Because Microsoft does throttle how much data that you push up to the cloud. Also, you have to--there's different considerations you have to take into account, permissions is another one. So if you want to access that shared mailbox of that monitoring mailbox and you're in the cloud and it's not, you can't really access that. Oh, so you're limited by premises. Yes, you are. So if you're on and it's off, and... Yup. You have to be in the same premises. You can't be split. You can't be hybrid. Ah, okay. Yeah, there is that limitation there. Also, if you have any network outage, you can't connect to the cloud. You need the network to get to the cloud. That's right, hmm. So if there is a network outage, some type of blip, there's no... People are without their email, which takes us back to monitoring and being able to monitor the environment. Okay, that's good. Now, I also—you know, in the webinar I mentioned earlier, we talked about just the migration. There's some limitations on the migration, if people have large mailboxes. Oh, yes, yes, yes. So, email sizes in Office 365. Well, the default is 25 megs, that's the size of your emails. Microsoft just recently announced that it's been increased to 150 megs. If you have 150 meg email, you're doing email wrong. That's just a really big email, my opinion. It's a pretty good one. Yeah, now when you're doing migrations into the cloud, one thing you should do is really look at the mailboxes, not just the size, but the content, especially if you've exceeded that now 150 meg size limitation, you have to figure out what you're going to do with those emails. Because they're not going up to the cloud. They'll get rejected, so there's a lot of planning involved, a lot of analyzing and researching. It could take weeks just going through all the different reports and looking at mailbox size, looking at actual content, attachments sizes, and then going okay, my throttling now. So, if I have a 20-gig mailbox, is that going to go up all in one day? Well, wait a minute, why wouldn't it go up in one day? Well, Microsoft does throttle how much data you push and also your network. How much bandwidth do you have to throttle up and down, there's a lot of math to it. It's not magically infinite? No, it's not. I can't just push it all up there? I wish, and I've seen some management feel that, oh, we have Office 365 now. We signed our enterprise agreement, let's make it happen, and we'll be done in three weeks. Sorry, if you have a large organization, and you've got hundreds of terabytes of data, it's not going to happen in three weeks. There's stage migrations. You can do cut-off migrations, but again, it's not going to happen in a day. Right, so all joking aside, just so people are aware, Microsoft limits how much data you can push up at a given time. And your network, as you mentioned, you network limits how much data you can push up at a particular time. So you're not going to be able to do an overnight transition to Office 365, not in any sort of sizable organization. That's really good. I know that we've talked a little bit about monitoring. We've talked a little bit about theory and cloud, and Office 365, the new stuff. What I really would like to do is get into some real, sort of hair on the knuckles, Exchange stuff, something that an Exchange administrator would see that would really give them a hard time, that's completely independent of monitoring or any of that stuff. So do you have anything that you can show us today that would just really speak to the Exchange admins? Do you really want to know my opinion? [Laughing] Uh, okay. So, tell you what, we were talking before about the, there was a key, a legacy... legacyExchangeDN value? Yes, can we go over that? Do you have some time for that? Guess we can go over that a little bit. Okay, I have a system set up here, so let's just dive into it. So, legacyExchangeDN value, the myth. It's a legend. It's annoying sometimes. It often creeps up during migrations, whether you are migrating from a different Exchange environment, let's say you have a merger, and you're joining companies. Okay. Also, it creeps up a lot of times with Office 365 migrations. Or, it can happen when you have a user who has a mailbox. They get deleted by accident for some unknown reason… On accident. By accident. Because they cut you off in the parking lot, not that I know. Yeah, and then the mailbox gets recreated with the same name and then someone goes, oh, I want to email that person. So, the legacyExchangeDN value error, you'll get this strange bizarre email from Exchange that says, "Hey, your email could not be delivered." Oh wait, okay, we can show everyone that. Okay, we get to do a chart, ready, there. So, you see there it says that it's undeliverable and to check your email and you get this strange string of characters, it looks like an email address. It looks like your distinguish name in AD, and you're like, what is this? I know this person exists. I know there's a mailbox, but why doesn't Outlook deliver this? Right. So, the history behind the legacyExchangeDN value goes back to the old NT days when Exchange had its own directory service and that was an attribute for Exchange. Now, it changed when AD came along. And for us not to go into a whole thing with AD, so pretty much, it's something that is legacy that Outlook still uses. And Outlook uses that DN value and when that DN value changes, it basically freaks out and says, I can't send to you, even though that email address is the same, that user is there. So what we have to do is we have to decipher that strange message coding and Microsoft provides a really good article. I use it a lot. Pretty much, you have to decipher it and put it into an x500 address. So essentially, you're creating another proxy address for your mailboxes so that Outlook can send to it again. Okay. And for me, I've done multiple migrations with acquisitions and what we would do is, we would actually take all the legacy DN values of that old environment and populate it into the mailboxes using a script. So when the migrations would happen and everything's done, the users on this side, once they've been over it, they can still email the users because their auto cache will still think, oh well, it's going to go to the old DN value. Because we replaced it in the proxy address. And what you can do, which is disruptive, is you could tell your users to clear out their auto cache, but most users don't like to do that because they like that auto cache in Outlook to populate. They like to just go, oh wait, there's that name. I'm going to click it, and there you go. So when we add the legacyExchangeDN value as an x500 proxy address, you just go into the Exchange console, Okay. Go into email addresses and it would be another address, and you just type in x500. And then you would use the KB article from Microsoft to decipher that cryptic, long distinguish name into a DN value, and you click OK, and you're done. Wow. Now if you're doing a migration, like I said before, you would script all this. You would grab everything out and put it in a text file, and pump everything into your new environment. But when you have these one offs, you would just--it's as simple as just going and adding an x500 address. And it sounds like one of those things that once you know the trick, it's not that big a deal, but if you don't know, there goes easily a day of trying to figure out what's going on. Yes, I've actually had some friends from around the world going, “Oh, we're trying to send to this distribution list.” Because it can happen with distribution lists as well. Great. I've actually seen that. Where you delete it and it had a DN value, and someone's still trying to send to it because they've recreated it. So I've helped out a lot of people to figure out. Oh, it's your DN value. And they've spent like a least two or three days trying to figure out why this email hasn't gone through. And a lot of times those messages that Exchange sends you, it's pretty, even though it seems cryptic, it's pretty informative if you have a history and you know what you're looking at. Great. And, that's what we've got for DN value. It's a myth and it's a legend, but it exists. Excellent. Hey kids, that was fantastic. It is so nice having a guest on the show. Well, I think that was a good start and now, I'm feeling so much better. Awesome. Good. And besides, these heels are killing me. Well, better you than me. So I think we can leave it here. That sounds great, and in fact, we're really interested to know what you guys think, so make sure you give us plenty of suggestions in the chat and at our homepage about what you'd like to see in future episodes. Right. Which reminds me, if you aren't seeing a big orange chat window over that way, it means you aren't watching us live. If that's the case, head on over to lab.solarwinds.com and register for upcoming episodes, so you can join us, as well as sign up to get email reminders, and even leave comments about what you'd like to see us cover in future episodes. Absolutely, and Phoummala, thank you so much for coming. It's been really great to have you on this week's show. Thanks, it's been really fun here. All right. Well, you want to do the honors and take us out? I'd love to. For SolarWinds Lab, I'm Phoummala Schmitt. I'm Leon Adato. And I'm Patrick Hubbard, and thanks for watching SolarWinds Lab. Cheers!
