Install Exchange Server 2013 Management Tools when there is no DC at your site

Trying to install the Exchange 2013 Management Tools, I kept receiving an error that setup couldn't proceed because "Setup must use a domain controller in the same site as this computer". The log files indicated "Failed [Rule:DomainControllerIsOutOfSite]". I was trying to install these tools onto a computer in a Site that did not have a DC. Using the unattended setup with /DomainController didn't help, as it wasn't that it couldn't find a DC, but there was no DC in my site. Unfortunately for me, sites were setup for SCCM, and some didn't have DCs. Here is how I finally worked around it and installed the Management Tools quickly, with only changes to the PC - no reboot required.

1. Navigated to HKLM\System\CurrentControlSet\Services\Netlogon\Parameters in the Registry Editor.

2. Created a new String Value (REG_SZ), called SiteName, with a value of the Site where the DC was located.

3. Kicked off the installation again, which completed successfully.

4. Deleted the SiteName registry entry after verifying the Management Tools were installed.

Would this work on a full server installation?  Possibly. However, I certainly wouldn't recommend attempting it for anything other than a critical system outage situation.

Exchange 2013 Suspended Migrations (staging mailboxes for a mass cutover)

I have read a number of articles on using the new-moverequest -SuspendWhenReadyToComplete:$true parameter. I have read a number of places where they are supposed to automatically re-sync every 24 hours. I have not found this to be the case for me, but I'm not sure if others are wrong, or whether there is an issue with my configuration. Either way, I'm glad they don't, because that allows me to force the re-sync on my own.  Here is what I've found to pre-stage the mailbox migrations to do a mass-cutover.

I am creating a batch of move requests with a CSV (with an Alias and Destination Column) and my command looks like this:

Import-CSV C:\Temp\mailboxes.csv|ForEach-Object{New-MoveRequest $_.Alias -TargetDatabase $_.Destination -BatchName "Human Resources" -SuspendWhenReadyToComplete -AllowLargeItems -BadItemLimit 1000 -AcceptLargeDataLoss}

To view the stats:

get-moverequest -BatchName "Human Resources"|get-moverequeststatistics |select percentcomplete,bytestransferred,overallduration,displayname,status,statusdetail,LastUpdateTimestamp,*ItemsTransf*,*stalled* |Out-GridView

To resync:

Get-moverequest -BatchName "IT"|Set-MoveRequest -SuspendWhenReadyToComplete:$true

Get-moverequest -BatchName "IT"|Resume-MoveRequest

The information I read indicated you need to set the SuspendWhenReadyToComplete to false to allow it to complete. I have found this not to be the case. Whenever I run the resume-moverequest, that flag automatically gets set back to false.  That means if you have autosuspended mailboxes and you do a resume-moverequest on them, they will complete UNLESS you set the SuspendWhenReadyToComplete to True first.

I've used these steps to kick off a re-sync of each batch, one a time, to prevent too much load on the server.

List all Exchange mailbox sizes for all people that report up to a single manager (direct and indirect reports of a manager)

If you track a manager for a user in Active Directory, then you have the ability to report on everyone that reports to a specific person by calling the directReports system only attribute.

get-aduser username -properties directReports | select directReports | fl

However, there are a number of things you can do with this that come in handy.  For me, I was tasked with reporting on how much space was consumed in Exchange mailboxes broken down by Business Unit. Since ultimately each Business Unit had a specific leader, I was able to utilize the directReports attribute to get everyone that reported up to the leader of the BU, then grab all their mailbox sizes.

There is a great post that got me started here: http://www.lazywinadmin.com/2014/10/powershell-who-reports-to-whom-active.html. That was very helpful to get me started with a function to list everyone that reports up to a specific person. I had to do some modifications in order to get what I wanted, but basically I switched to get-user to pipe properly to the get-mailboxstatistics command, then exported everything to a nice looking CSV for easy sorting.

My Version: (note...execute from Exchange Management Shell)

function ADDirectReports
{
param([string]$Identity)
Get-Aduser -Identity $Identity -Properties directreports|
ForEach-Object -Process {
$_.directreports|ForEach-Object -Process{
$MGR = (get-user $PSitem).manager|get-user
Get-User -identity $PSitem|get-mailboxstatistics|select Database,DisplayName,@{label="Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{ L = "Manager"; E = {$MGR.DisplayName}}|Export-CSV -Path C:\Temp\Mailboxes.csv -Append -Confirm:$false -NoClobber
ADDirectReports -Identity $PSItem -Recurse
}}}

(Tip for PowerShell Beginners...paste the function into your PowerShell Window...then press enter twice...once you get back to the command prompt, type in ADDirectReports USERNAME and press enter to gather this information for all the reports of a top level manager).

This creates a CSV that looks as follows in Excel:

PowerShell script to purge log files older than x days

I've run into many situations where I have run low on disk space due to log files that are in desperate need of purging. Sometimes it is IIS, but I find it applies to a wide array of programs and I have searched high and low for a good option that doesn't cost anything. I wanted to share what I've come up with that has been working well for me. Since I'm in PowerShell on a daily basis running other commands, I created a LogCleaner.Ps1 script that goes to various servers and purges log files. Since some have log files I need to keep longer, I have a separate line for each server and I just add a line as I run into a new server with some new files that need to be purged.  This one hits an IIS server, SolarWinds Orion Server, a Generic Server, and a SharePoint server.

$now = get-date
get-childitem "\\server1.domain.com\c$\inetpub\logs\logfiles" -recurse| where {$_.LastWriteTime -le $now.AddDays(-7)} | del -Confirm:$false
get-childitem "\\server2.domain.com\c$\ProgramData\Solarwinds\Collector\StreamedResults\SolarWinds.Node.Wireless.Snmp" -recurse| where {$_.LastWriteTime -le $now.AddDays(-2)} | del -Confirm:$false
get-childitem "\\server3.domain.com\c$\Users\username\AppData\Local\Temp" -recurse| where {$_.LastWriteTime -le $now.AddDays(-1)} | del -Confirm:$false
get-childitem "\\server4.domain.com\c$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS" -recurse| where {$_.LastWriteTime -le $now.AddDays(-1)} | del -Confirm:$false

You could, of course, schedule this to run and place the script on each server, if you wanted. I like just kicking it off from my workstation so I can see any errors and have the warm fuzzy feeling that it has been run without checking every server.  Since I run this on a daily basis, it never takes more than a minute to run against the 30 servers I have it configured for at this time.

DNS Scavenging Simplified

I must admit that for years I was confused and afraid of DNS Scavenging. Horror stories of others losing lots of records and my own ignorance caused me to avoid it and disable it rather than learn how to configure it properly. After reading Microsoft's documentation and getting more confused, I stumbled across some comments someone made online that helped me begin to decrypt DNS Scavenging. Here is what I have learned over the years that I wish someone had just spelled out clearly for me long ago.

1. DNS Scavenging is almost always necessary. Unless you are managing all your DNS records manually, you really do need scavenging enabled to prevent duplicate DNS records and stale records for decommissioned servers. Without scavenging, you are much more likely to end up in a situation where two records exist for the same name, then you have a Round-Robin issue where half the time the resolution works and half the time it doesn't.

2. What the heck are the No-Refresh / Refresh intervals? In simple terms, the No-Refresh interval is the amount of time that the record is not allowed to be updated. This is to reduce DNS replication traffic. The Refresh interval is the amount of time that the record is able to be refreshed, before it is scavenged. I've seen many places where they set the No-Refresh interval to 7 days and the Refresh interval to 1 day. Unfortunately this drastically increases the likelihood of losing records.

3. Should I leave the No-Refresh / Refresh intervals at the default? Usually no. Microsoft recommends setting the No-Refresh and Refresh intervals to match the length of the DHCP lease.  This is to prevent two names pointing to the same IP address and causing reverse DNS lookup issues. What I find humorous is that the default for No-Refresh and Refresh intervals are both 7 days, but the default DHCP lease is 8 days. That means that out of the box, if you enable DNS Scavenging you are going to be likely running into issues.

4. Where do I enable DNS Scavenging? There are really two places that it needs to be enabled, and this is where I see most of the issues when scavenging isn't running at all. First, you need to pick a DNS Server in your environment to be the server that does the scavenging. There is no benefit to enabling it on multiple servers unless they host different zones. Having it enabled on multiple servers for the same zone can cause many issues when the scavenging runs at the same time. Right-click the DNS Server, then select Properties. On the Advanced tab, check the box to Enable scavenging. The Scavenging Period is how often you want the Scavenging to run. The default is 7 days, but I prefer to have it run every day.

After you enable it on a single DNS server, then you need to enable it for the entire zone. Right-click the zone, then click properties. On the General tab, click Aging. Check the box to enable scavenging and set your intervals. If your DHCP lease is 8 days, I prefer to set the No-refresh interval to 1 day and the Refresh interval to 7 days.

5. Is there anything I should do prior to enabling scavenging? YES!!!

• I recommend exporting a list of all your DNS records, in case you need to add any static entries after scavenging runs. You can do this by clicking on the DNS Zone and waiting for all the records to enumerate. Then right-click the DNS Zone and select Export List.
• Check all your servers to see the timestamps if they are not static entries. This will tell you whether updates are happening for your important records. 
• If you want to be extra careful, you can prevent a record from getting scavenged by selecting View, Advanced in the DNS Manager, then double-clicking on your DNS entry. You will now see a box that says Delete this record when it becomes stale. To prevent a record from being scavenged, simple uncheck this box. Prior to implementing DNS Scavening, I highly recommend doing this to every server, just as a safety net to make sure nothing critical is scavenged by accident.

This is not intended to be an exhaustive list of everything related to DNS Scavenging. My intent was just to demystify some of these settings for sysadmins so they can feel more comfortable enabling these features.

Exchange 2013 Authenticated Relay Possible Gotcha

This might never happen to anyone else, but just in case, I wanted to save someone lots of time troubleshooting the problem.

Background: Upgrading from Exchange 2007 to Exchange 2013, one task was to point our email relay DNS name from the Exchange 2007 environment to Exchange 2013. This handled authenticated relay as well as anonymous relay.

Problem: Once we moved the DNS name, authenticated relay from our printer/fax/scanner systems stopped functioning. We received a generic SMTP error. Unchecking authentication in the configuration and using anonymous relay worked fine when we added the IP address.

Solution: I discovered the account being used on the problem devices was a generic user account without a mailbox. The username was something like scan@domain.com, while the devices were configured for noreply@domain.com. This worked fine in our Exchange 2007 environment, but to get it to function in Exchange 2013, I had to mail enable the user account, then add the specific noreply@domain.com as a proxy address to the mailbox.

Note: It would have certainly been possible to reconfigure the devices to use a different account, or a different send from email address, or even switch them to anonymous relay.  However, in a large migration with many of these devices, it is easy to miss some. I wanted to ensure a smooth transition and address reconfiguring these devices later.

Common mistakes with Windows DHCP Configurations

Changing DNS settings to "Always dynamically update DNS records"

There is a very common misunderstanding that takes place frequently in relation to this setting. Common sense would indicate you should select this option to make sure DNS records are always updated. However, we're not supposed to use common sense here. What this setting doesn't mention, is that the default option of "Dynamically update DNS records only if requested by the DHCP clients", means that the DHCP client will update its own record automatically and only ask the DHCP server to do so if it is unable. One example of it being unable to update the record is if the record was already created and the computer account doesn't have permissions to that record. Unless you know for certain you have a case for changing this, then leave it at the default. If you are having issues with records updating, then most likely you have a DNS Scavenging issue, not a DHCP issue. If the second option to Always update is selected, then the DHCP server tells the client not to update the record, that the DHCP server will handle it. What's the problem then, Wes? Well, most people forget to configure credentials for the DHCP server, which means if you have installed DHCP onto a DC, you are in an extremely vulnerable configuration, or you are simply unable to update the DNS records. What I've seen most frequently is that DNS isn't being updated because DNS Scavenging is not enabled.  Someone then sets this to Always dynamically update, then they don't configure credentials, and the DNS records never get updated. So if you are selecting the Always dynamically update option, don't forget to enter credentials.  http://technet.microsoft.com/en-us/library/dd145315%28v=ws.10%29.aspx

Conflict detection Attempts set to 0
While we are on this screen, make sure you set the Conflict Detection Attempts to at least 2. Microsoft recommends setting this option to allow DHCP to send a ping to an address before handing it out. This is useful in preventing IP address conflicts when someone manually assigns an address within a DHCP range. I prefer to set it to 2 since I have seen some environments where a switch might not have an entry in the ARP table for that MAC address, and it drops the first ping, but then finds it. By setting it to 2, you can ensure that you have given your switch time to update the ARP table and aren't relying upon a single ping before handing out the address. If you're concerned about slowing down the process, I wouldn't worry about it. Having made this change in dozens of environments, I never ran into anyone that was able to notice the difference in boot times of the clients.

Not enabling scavenging in DNS
I will go into more detail in another post about DNS, but I do want to mention that scavenging should be enabled and the Refresh/No Refresh interval should equal the length of your DHCP scope. If you are scared to enable scavenging, good. You should have a healthy fear of screwing up your environment. I highly recommend exporting your list of DNS addresses prior to enabling scavenging. However, don't let the fear of issues prevent you from configuring your servers properly. DNS Scavenging can be configured to work properly. Let me repeat. DNS Scavenging can be configured to work properly!

Forgetting to remove or update legacy Authorized DHCP Servers
While it usually isn't the end of the world, it is possible to put yourself in a pickle by leaving legacy addresses in DHCP as authorized servers. Not likely, but while you are in and cleaning things up, this is a good place to look. Right click DHCP, then select Manage Authorized Servers. Make sure you only remove the old IP addresses. If you authorized a DHCP server, then replaced it later with a server with the same IP address, but a different name, you will want to make sure you unauthorize the old one with the wrong name, then authorize the new one. I've seen situations where an old authorization works because the IP address is the same, but then someone deletes that authorized server later because the name is different. Then everyone stops getting DHCP addresses until someone realizes they need to add that DHCP server back into the authorized list.