Find Stale Computer Accounts in Active Directory

The simplest way to find old unused computer accounts is by using a PowerShell query. You can use Get-ADComputer to do the query. In smaller environments, you can do a simple query for all computer accounts sorted by LastLogonDate. This query puts the oldest logon dates at the top:

Get-ADComputer -Filter * -Properties LastLogonDate | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate

The -Filter parameter is required, by using an asterisk, you are querying for all computer accounts. You need to use the -Properties parameter because the Get-ADComputer cmdlet doesn't query for all computer account properties by default. So, you can use the -Properties parameter to specify that LastLogonDate should be retrieved.

Be aware that servers will be included in this list and that LastLogonDate is not entirely accurate when identifying whether servers are in use. For example, I just did a query for a client with an active application server that shows the LastLogonDate as being three months ago. However, I know for sure that clients are actively using the application on that server.

The idle time for computers in your organization may vary. So, for desktop computers 3 months or so is probably a good guideline for identifying unused computer accounts.

In a larger environment you don't want to see all of the computer accounts listed by your query. Instead you want to see only the accounts that you may be concerned about that haven't logged on for a certain timeframe. The command below queries only computer accounts that have not logged on for 90 days.

Get-ADComputer -Filter * -Properties LastLogonDate | Where-Object {$_.LastLogonDate -lt (Get-Date).AddDays(-90)} | Sort-Object LastLogonDate | Format-Table Name,LastLogonDate

Port 25 Blocked for Specific Domains

This was such a strange issue that I don't know if this post will ever help anyone. I just need to write it for therapy......

Starting on Friday of last week, I got reports from one client that some emails were not being delivered. This has happened to clients in the past when they were on block lists. So, my first step was to check some block list tools to see what's up. Each of the block list tools indicated that the IP was not being blocked.


Some of the antispam appliances have block lists that are not checked by the typical web sites. So, I tried to dig into it a bit further. One of the sites that was being blocked is a local university and I know several of the server/email admins there. So, emailed, explaining that I figured it was an antispam issue. They sent me the site to check block list for their appliance and it came up clean. In fact, they said my request for delivery wasn't showing up in the logs at all.

I should also note that access to ports other than 25 was unaffected. You could do ping the IP of the mail servers and connect to websites on that IP if a website was there. Only port 25 connectivity was blocked.

One of the things I had tried to do was use Putty (a free telnet client) to telnet to some of the failing email servers. Often the email server provides a message that indicates which antispam product is being used so that you can investigate why you're being blocked. In this case, each of the attempts to connect ended with a dropped connection.

Of course my other concern is that the firewall has gone nuts and is blocking things that it shouldn't. So, I did some logging and testing of rules. Nope, didn't look like the firewall was blocking anything.

As the suggestion of the admin at the university, I called the ISP. The admin at the university indicated that they had a call from someone else on Bell that couldn't deliver to them also. Weird....

So, next step is call the ISP. In the past my experience with ISPs and tech support has been rather poor overall. In this case Bell was great, they took the info and began investigating. They didn't blame my configuration. They also came back and indicated that it was their connectivity through Shaw that was the issue. So, anything being delivered to Shaw or routed through the Shaw network was affected.

It took about 5 days for Bell to convince Shaw that the issue was on their network, but the problem is now resolved. My best guess is that Shaw was marking the traffic from Bell like they do consumer Internet tracking and blocking port 25.

Need to Find Your Android Device?

This web page allows you log on with your Google account (which was required when getting the device online) and shows the location of your device. You can wipe it if you lost it. You can also ring it to find it in your house.

• https://www.google.com/android/devicemanager

The hard part is remembering the credentials for your Google account if you don't use it very often.

Script to Resolve Error When Running Enable-RemoteMailbox

If you have existing user accounts in your hybrid environment, and want create a mailbox in Office 365 for those users, you can use the Enable-RemoteMailbox cmdlet. However, when you try to use Enable-RemoteMailbox you commonly get the following error:

The address '@yourtenant.mail.onmicrosoft.com' is invalid: "@yourtenant.mail.onmicrosoft.com" isn't a valid SMTP address. The domain name can't contain spaces and it has to have a prefix and a suffix, such as example.com.

This error occurs because the cmdlet is not building the RemoteRoutingAddress properly. This address is used for routing messages to the Office 365. So, we need to create that RemoteRoutingAddress property as part of a piped command or script.

I've seen several examples using piped commands, but I prefer a script because I find it easier to follow the logic. Here is the script I used recently:

$users = get-user -OrganizationalUnit "OU=xx,DC=domain,DC=com" -RecipientTypeDetails User 

foreach ($u in $users) {
   $alias = $u.FirstName + "." + $u.LastName
   $RR= $alias + "@yourtenant.mail.onmicrosoft.com"
   Enable-RemoteMailbox -identity $u -RemoteRoutingAddress $RR
}

This script obtains a list of users without mailboxes from a specific OU. Then it loops through that list of users, takes user properties to build the remote routing address in the variable $RR. Finally it enables the remote mailbox for each user.

When you use the Enable-RemoteMailbox cmdlet, it also automatically adds that remote routing address as an email address for the account. Which is of course required for Office 365 to accept the mail.

Exchange Hybrid Mode and Dynamic Distribution Groups

Exchange Online/Office 365 does not have dynamic distribution groups. So, in a hybrid deployment, it's not possible to synchronize dynamic distribution groups from on-premises to Office 365. There are two work arounds:

Option 1
If you like scripting, you can create a script that updates the membership of a normal distribution group. You'll need to run the script as a scheduled task. The main benefit to this method is that it is contained entirely within the on-premises environment.

There are two drawbacks to this method:

1. It's not actually dynamic, so there is a lag time from when new members are created and when they're added to the group.
2. It's relatively complex to create the script and schedule a powershell script to run as a task with the correct snap-ins loaded.

Option 2
My preferred option for this is to create a contact in Office 365 that points at the dynamic distribution group on-premises. This allows you to continue using true dynamic distribution groups on your on-premises environment and give Office 365 users the ability to send messages to them.

When you create the dynamic distribution group you need to select the following recipient types:

• Users with Exchange Mailboxes. These are your on premises users.
• Users with external e-mail addresses. These are your office 365 users.

After you create the dynamic distribution group, collect the following information from it:

• Display Name
• Alias
• Email address (not the mail.onmicrosoft.com address)

Now use the Office 365 admin console to create a mail contact (do not create on-premises contact and sync it) with the following attributes:

• Display Name: same as dynamic distribution group
• Alias: same as dynamic distribution group
• External email address: same as email address from dynamic distribution group

From a management perspective, this is a bit of a pain because you need to remember to manually create an extra contact in Office 365. However, I still think this is the easiest way to get it going.

You can't create the contact locally and sync it for two reasons:

1. You can duplicate the same display name on two objects. So, you'll end up with two objects using the same display name. This will be confusing for on-premises users who will see both objects.
2. You can't duplicate the external email address for a contact with the actual email address for the dynamic distribution group. This makes it not just a bad idea, but a technical impossibility.

Exchange Online Limits

When you implement Office 365, you are using Exchange Online for email. Exchange Online is regularly changing the limits that apply for things like the size of the mailbox and attachment sizes. This web page is maintained with the up to date information on limits for Exchange Online:

• http://technet.microsoft.com/en-us/library/exchange-online-limits.aspx

Trigger a Full Sync of Passwords for DirSync

Normally the only time you need to do a full synchronization of passwords with DirSync is after you install it. By default, when you complete the configuration wizard it performs a full synchronization of passwords. After that point passwords are synchronized only accounts are created or when the password is changed.

One potential issue that can pop up is changed passwords on the Office 365 side. When passwords are synchronized to Office 365, it is still possible to change them in Office 365 for the user account. This is not recommended from a management perspective, but administrators make bad choices once in a while. When this happens the account is out of sync between on-premises and Office 365.

To ensure that all passwords in Office 365 match their on-premises account, you can trigger the same type of full password synchronization that occurs after DirSync is installed. Perform the following steps:

1. Open a Windows PowerShell prompt.
2. Type Import-Module DirSync and press Enter.
3. Type Set-FullPasswordSync and press Enter.
4. Use the Services console to restart the Federation Identity Manager Synchronization Service.

Note: If you try to use the Restart-Service cmdlet to restart the Federation Identify Manager Synchronization Services, you will need to use the -Force parameter and it will not restart the Windows Azure Active Directory Sync Service properly.

You can verify the synchronization was successful by looking for Event ID 657 in the Application event log that shows the passwords being synchronized.