PowerShell

How to check Exchange Online Distribution List activity over 30, 60, 90+ days?

All growing and/or large organizations will experience this. We have all of these Distribution Lists, but does anyone even use them or know why they were created 5, 10, 15 years ago? I recently ran into this at work, where we are trying to figure out if we can safely delete specific Distribution Lists. They have members, but most of the members have no idea they are a member, or why they would even need the email address.

As always, I start my investigation into how to do something with a quick Google Search. I stumbled upon a bunch of articles specific to Exchange on-premises, and a few items on how to see usage in the last 10 days, but nothing more. The next issue with the ones I did find for Exchange Online was only going to handle 1000 email messages, more than that, and you have to add additional parameters to the command and page through the command multiple times for more than 5000.

I knew many of these lists most likely have infrequent usage, if any at all, so 10 days wasn’t going to cut it. My resolution to this problem? Scheduled tasks, and time!

Before you can run this script, you need to make sure you install the Exchange Online Management PowerShell Module. The module is on the PowerShell Gallery.

The script itself is pretty straightforward. It would be best if you had a secure way to store your passwords that the script will use for authenticating to Office 365. My example script will only work in interactive mode, and you need to dig a bit into storing credentials securely. I would recommend checking out David Lee’s post “Using saved credentials securely in PowerShell scripts” for more information.

Connect-ExchangeOnline -UserPrincipalName user@example.com

$date = Get-Date

$fullResults = @()
$i = 1
do{
    $trace = Get-MessageTrace -Status expanded -startdate ($date).AddDays(-10) -EndDate ($date) -PageSize 5000 -Page $i| Group-Object recipientaddress | Select-Object name,count
    $fullResults += $trace
    $i++
} until($null -eq $trace)

$fileName = (Get-Date -Format "yyyy.MM.dd") + "_DLUsage.csv"
$fullResults | Export-Csv "C:\Reports$fileName" -NoTypeInformation

All you need to do is update the script to use a securely stored credential and set a scheduled task to run at the same time every 10 days. After however long you want to look at historical data, you import to an Excel spreadsheet and compare!

Tracking and Automating Business Processes

As businesses grow, it becomes challenging to keep up with business processes. To keep up with a constant flow of tasks associated with these processes, you need to track them, especially when multiple people are involved with the process. Business processes become difficult when you have to enter data into multiple systems. Entering the same data multiple times increases the risk of human error each time data gets entered.

In recent months I’ve been tasked with helping different business units improve and track their processes. Specifically, I started with our onboarding experience. The process tasks get assigned to people that are geographically dispersed, and sometimes the people involved with the onboarding only do a few a month. There is a lot that needs to go into it. You want to factor in things such as IT, Payroll, Equipment, Licensing, Training, which makes it keeping everyone in the loop difficult.

To combat these difficulties we settled on a product called TallyFy. TallyFy gives us a dashboard that will show us how our processes are progressing. It helps keep everyone on the same page and helps communicate issues in a more rapid manner.

Our hurdle with TallyFy was that it was tacking yet another system into our onboarding experience. We already had three different systems involved in someone applying for a job to ultimately receiving their first paycheck. Having multiple systems caused data re-entry, which is prone to typos. To combat the data re-entry, we needed to integrate our different systems. As previously blogged about I wrote a PowerShell Module to interact with the BirdDog HR system; we use this to send our new hires their employee packet to fill out before day one. This PowerShell Module I was able to query new in-coming employees – my next task was to integrate it with TallyFy so that it would track the progress of the onboarding.

Luckily for me, TallyFy has done a fantastic job writing an API that their web interface runs on, and I can do everything they can do. One of the challenges with this is that their API is very complicated. I’ve been lucky enough to work closely with their team to build out this PowerShell Module that only touches on a small fraction of what is available thought their API.

PowerShell Module Git Repository:

I am storing this Module on my personal Git Repository; as it is built out more I might publish into the PowerShell Gallery. You can find the Module at TallyFy API PowerShell Module.

Store the psd1 and psm1 files in Documents\WindowsPowerShell\Modules\TallyFy.

Connecting to TallyFy API

  1. Login to https://go.tallyfy.com
  2. Click on your name in the Top Right corner of site
  3. Click Settings
  4. Click Integrations
  5. Note your Client ID and Client Secret
  6. Open PowerShell and run the below command
  7. Connect-TallyFyAPI -ClientID 'Your client ID' -ClientSecret 'Your Client Secret' -Credential (Get-Credential) 
  8. Use your TallyFy Username and Password when prompted

Feel free to explore the other commands by running the below command.

Get-Help -Module TallyFy

Using PowerShell with RESTful API’s – BirdDogHR API Module

In the last few months at work, we have been concentrating on integrating different cloud-hosted systems with our on-premise systems. Integration usually means using some ETL Tool to interact with an API, and either use an API with the on-premise application or dumping directly into a Database.

We decided to start automating our Onboarding Processes. The hurdle came up that the ETL Tool isn’t going to trigger Account Creation and other IT related actions. My logical thought was I can interact with an API using PowerShell! I had done this a little bit in the past but nothing significant – so I had a bit of learning to do!

Building a Desired State Configuration (DSC) Lab

Recently I presenting at the Indianapolis PowerShell User Group and talked about Desired State Configuration. The presentation was 100% demonstrations, and I decided it would be a good idea to provide all of the PowerShell commands/instructions I used to build my lab environment for the presentation.

Note: Please note that these instructions were written using multiple Experimental DSC Resources, Microsoft and I myself provide no guarantee that these will work in a production environment. I strongly encourage that you use test environments that do not matter until you feel comfortable with DSC.

Pre-requisites

  • Licensed/Trial Media for Windows Server 2012 R2
  • An installed/updated Sys prepped VM Parent Disk
    • Stored at D:\Templates\Server2012R2.vhdx
  • a Virtual Switch within Hyper-V Configured as a Private, named “Private Network”
  • At least 7GB of free memory
    • You can adjust this all the way down to just 4GB
  • Downloaded copy of the latest DSC Resource Kit – Download Here

Now before we dive into the scripting component of this blog post I want you to know that this is not 100% automated. You will have some manual steps here and there, it is possible to 100% automate – but that will require significantly more effort. Please continue reading for instructions on this demonstration.

PowerShell: Check for user accounts running Windows Services

Recently I worked with a client to validate that if a user account were to be disabled that it wasn’t going to break any of their currently running applications. You can be bitten by an accidental miss-configuration where an end-users account is running a Windows Service or possibly at a lower level in a specific application such as SQL Server jobs. Luckily with the Power of PowerShell, we can conquer the Windows Services! It is also possible to create a SQL Query or even PowerShell scripts to query SQL, but we are not covering that in this article.

Checking Windows Services:

The biggest concern I had was the Windows Services. It is easy enough for a junior admin to install SQL and specify their account as the Service Account, THIS IS BAD! However, with some pure PowerShell, we can perform a visual inspection, or with some minor adjustments, we could look for a service running with a specific user.

Get-CimInstance -ComputerName (Get-ADComputer -Filter 'OperatingSystem -like "Windows Server*"' | Select -ExpandProperty Name) -Query "SELECT Name, StartName FROM Win32_Service WHERE StartName <> 'LocalSystem'" | ? { $_.StartName -notlike 'NT AUTHORITY*' -and $_.StartName -notlike 'NT SERVICE*' } | Select Name, StartName, PSComputerName

In the above example, we are using a parenthetical command along with the Get-CimInstance Cmdlet. The command that executes first is the Get-ADComputer. This command requires the ActiveDirectory module is available on your computer system. It uses the filter parameter to look for any computer that is running Windows Server (any version).

Then it passes those values to the Get-CimInstance, which performs an initial WQL Query, which doesn’t allow and statements. Therefore, we have to pipe it’s returned values to a where statement which continues filtering for us. The end of the command provides the service name, the user account running it, and the computer this service is on.

I was able to run this against the client’s environment, and within a few minutes, we knew it was safe to disable the account.