Category: Uncategorized

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).

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).

A new Toolbox…

Update: May 2022 – The toolbox.com domain now redirects to spiceworks.com.

Almost a decade ago, I started a professional blog on [the now defunct] it.toolbox.com called “IT Champloo”. At the time, IT Toolbox was a thriving community of professionals sharing advice, experiences, and wisdom.

Over the years, the platform’s performance and usability slowly declined (as did my interest in creating content for a site where banner ads were given more real estate than my articles).

When the domain, yousefalahmad.com became available, I decided to snatch it up and migrate my content to it. This blog will serve as a repository for tips, tricks, commentary, and observations in the hopes that they might be of use to someone later down the road.

How To: Resolving a System Hang During Patching, Remotely!

Routine patching of systems and software is a crucial piece of any business’ information security strategy. Even so, many systems go unnoticed and unpatched for months, even years until an external threat forces the organization into action (e.g. the recent WannaCry ransomware outbreak).

When that happens, server administrators need to be prepared for irregularities they’re likely to encounter, such as a hang prior to reboot.

In this scenario, we’re going to assume that you’ve just finished patching and clicked the “Restart Now” button. You begin a continuous ping (ping -t [hostname/IP address]) and wait for the server to restart.

Let’s assume a normal reboot takes 5-10 minutes for this machine, and that 25+ minutes have passed.

You check the console, and are greeted by the “‘Preparing to Configure Windows. Do not turn off your computer” message. Time continues to pass while your maintenance window dwindles like falling grains in an hourglass… pressure is mounting, the business won’t wait. Time for action!

Logged in as an Administrator from your workstation check the Windows Module Installer service on the remote system…

  1. Run services.msc
  2. Right-click “Services (Local)” and select “Connect to another computer …”
  3. Make sure the “Another computer” radio button is selected and enter the hostname of the stuck server and click “OK”
  4. Search for “Windows Module Installer” service and verify its status. If it’s “stopping,” then you will need to force it to stop. This can’t be done here, so we’ll need to query its PID and use our old friend TaskKill to manually kill the service

Query the Process ID (PID) of the Windows Module Installer (TrustedInstaller) service…

  1. Open Command Prompt as an Administrator
  2. Run the following command:
sc \\[hostname of the server] queryex trustedinstaller

This will return (among other information) the PID of the stuck service, write it down as you’ll need it for the next step

Kill the hung service remotely using TaskKill…

  1. From the Command Prompt already opened, run the following
command:taskkill /s [hostname of the server] /pid [PIDFromAbove] /f

Congratulations, your system should now be unhung! Check your console or continuous ping to verify that the system is restarting and proceed to the next round of updates.