Author: Yousef Alahmad

If at First Your Don’t Succeed, CLI, CLI Again!

I recently encountered the following error when attempting to update the default antispam policy GUI (https://security.microsoft.com/antispam) for a new client’s Exchange 365 tenant:

“…The command you tried to run isn’t currently allowed in your organization. To run this command, you first need to run the command Enable-OrganizationCustomization.”

So, I fired up an instance of Exchange Online PowerShell and tried to run the Enable-OrganizationCustomization cmdlet…

Connect-ExchangeOnline
Enable-OrganizationCustomization

…but I was told it was already enabled!

“This operation is not required. Organization is already enabled for customization.”

If the CLI was insisting that Organization Customization was already enabled, who was I to argue? So, I switched gears and attempted to implement the change through PowerShell instead:

Set-HostedConnectionFilterPolicy -Identity Default -IPAllowList [IP Address]

Not only did this work, but the change was also reflected in the GUI! Subsequent changes through the GUI were also successful (i.e., no more prompts to enable Organization Customization).

Targeted Email Removal with Exchange Online Powershell

In the course of administering an Exchange Online instance I’m occasionally asked to locate and remove an email (or set of emails) from the entire tenant. The quickest way to do this is via PowerShell:

Connect to the Exchange Online instance, enter your credentials when prompted:

Connect-ExchangeOnline

Next, Connect to the Security and Compliance Center PowerShell, entering your credentials again when prompted:

Connect-IPPSSession

Now that you’re connected, you can create a new compliance search to locate the email(s) you wish to remove:

New-ComplianceSearch [SearchName] -ExchangeLocation 'All' -ContentMatchQuery 'from: "*@something.com"'

In the example above, I’m searching for all content across all mailboxes from a specific domain (e.g. @something.com), but you can modify the scope of the search by adjusting the location and content match query (i.e. searching by subject or just looking at specific mailboxes/folders etc.).

Once the search is created, you will need to start it:

Start-ComplianceSearch [SearchName]

While the search is ongoing, you can check on its status:

Get-ComplianceSearch [SearchName]

NOTE: You can use the “|fl“ parameter to obtain additional information on the compliance search status.

Once completed, you can use the purge the emails located by the search:

New-ComplianceSearchAction -SearchName [SearchName] -Purge -PurgeType SoftDelete

 

Parameter Hunting: Part II

In my last post on the subject, I discussed the concept of using Process Explorer to discover switches you can use for unattended installs/uninstalls used in enterprise software deployment.

Like before, I have a pesky setup.exe package that wants to guide me through an installation GUI, and would not respond to the usual setup.exe /s /q etc. and so forth…

This particular installer was for a very obscure serial hub manufacturer so there was Googling my way out of this; instead I needed to figure out what was used to build the installer, then work backward from there.

Once against, I launched my trusty Process Explorer (as Administrator) and inspected the setup.exe’s process…to my delight, scrolling down the “Strings” tab I came across this:

Note the string, “This installation was built with Inno Setup.” With that in mind, I was able to look up the documentation associated with the package builder to discover the built-in parameters I needed for silent installation.

While this specific technique might not work for every situation, it never hurts to have another tool in your toolbox!

Email Hide and Go Seek: How to locate a specific email (down to the folder) in Office 365 using PowerShell

In many organizations, end users receive too much email to manage effectively. Many utilize rules to filter emails into specific buckets to make them easier to find. Over time, these rules compound, and could eventually lead to unintended consequences (i.e. receiving an email but being unable to find it).

When this happens, I’d typically run a quick message trace to establish whether the email was actually delivered or not. Many admins will stop there, advising the end-user to check their rule settings, but using PowerShell, we can find the email(s) for them!

First, let’s get logged into the Office 365 tenant:

$Credential = Get-Credential
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $ExchangeSession

Next, we can determine how many emails match the criteria in case there are more than one (Optional):

search-mailbox -EstimateResultOnly -identity [target user] -searchquery 'from:"[sender emai]" AND subject:"subject"'

Now for the coup de grâce, to reconstruct precisely which folder and sub-folder(s) of where the email(s) that match that criteria are in the user’s inbox:

search-mailbox -identity [recipient] -searchquery 'from:"[sender]" AND subject:"[subject] "' -targetmailbox "[your email] " -targetfolder "SearchResults"

In your inbox, you’ll see a folder called ‘SearchResults’. Using this, you can guide the end-user through the folder structure on their own Inbox that they’ll need to traverse to get to the desired email(s).

Parameter Hunting

Preface: Often in our line of work, the answer requires a little digging. The purpose of this post is to walk you through my thought process in an effort to illustrate how I go about linking disparate pieces of information together to arrive at a solution.

Last week, I was tasked with creating a script to silently uninstall an application across a managed environment with nearly 800 endpoints spanning multiple physical locations and at least 3 separate domains – that was the easy part.

The hard part was that this application was installed as .EXE file rather than an MSI package (i.e. I couldn’t just script out msiexec /x…). While it did have an uninstall.exe file, this called the GUI uninstaller, and I wasn’t about to have someone go through and click ‘next’ ‘next’ ‘next’ for each one!

Many .EXE’s have CLI parameters you can invoke, so I started with the usual suspects:

  • uninstall.exe /?
  • uninstall.exe –?
  • uninstall.exe /help
  • uninstall.exe -help
  • uninstall.exe –help

None of these worked (it wouldn’t be post-worthy if it was that easy)!

Next, I went looking for any documentation that was available for the application – I had:

  • Googled the manufacturer for any documentation/examples – nada
  • Read all of the .txt files in the installation folder – zilch
  • Reviewed the .ini and .config files for clues, saw something vaguely useful – a reference to “NSIS” – tabled it and kept looking

Finally, I decided to use SysInternals Process Explorer to inspect the application:

  1. Run the application you want to inspect
  2. Open Process Explorer (as administrator)
  3. Find the application on the list
  4. Right click on the application and select “Properties…”
  5. Under the “Image” tab, you will see a field for “Command line:”

The Command line will tell you what commands/switches it runs. In this case, the uninstall.exe was running with the switch, “_?=C:\Program Files\[Application Name]”.

I decided to Google the switch itself, which lead me to the Nullsoft Scriptable Install System documentation. I was able to work out that the application used NSIS to create the installer/uninstaller package, and through that, found some examples, one of which (/S) runs the installer/uninstaller silently!

This was exactly what I was looking for! All I had to do was append the command with “/S”, and sure enough, it removed the application without any prompts or launching the GUI!

It just goes to show that persistence pays off, and a little time and effort can save your organization/client hundreds of hours of manual work.