Tag Archive | powershell

Using Exchange to prevent information leakage by your idiot staff who can’t type

Wired published an interesting article this week about the use of what they call ‘doppelgänger domains’ that collected email sent to misspellings of the domains of a number of large companies. The headline of their report?

Researchers’ Typosquatting Stole 20 GB of E-Mail From Fortune 500

The intercepted correspondence included employee usernames and passwords, sensitive security information about the configuration of corporate network architecture that would be useful to hackers, affidavits and other documents related to litigation in which the companies were embroiled, and trade secrets, such as contracts for business transactions.

“Twenty gigs of data is a lot of data in six months of really doing nothing,” said researcher Peter Kim from the Godai Group. “And nobody knows this is happening.”

(more)

The best part is that their 120,000-strong haul of misaddressed emails, over 6 months, came from only 30 dummy domains (though probably carefully-chosen ones).

This had never really occurred to me before, but I immediately got to thinking about the bad typists in my own school. I imagine you have at least as many in yours. These are people who routinely share passwords with one another, dismiss Data Protection as nothing but red tape, wouldn’t hesitate to put login details in an email, and have fatter fingers than the Stay Puft Marshmallow Man.

I then checked a few common typos of our school’s domain name. All the ones I picked were registered by typo squatters. I fired off some emails to headmaster@ for each one. 1 bounced. The others disappeared, possibly to a black hole, possibly to a catch-all. The point is, I have no way of knowing.

This is a problem.

Read More…

How to get a list of every WSUS update using PowerShell

Recently I needed to get a list of every update on my WSUS server, due to a bug in System Center Essentials which leaves orphaned folders on the server even when locally-published updates have been removed using the console (the Server Cleanup tool doesn’t get rid of these files either – see this post on TechNet.

The folders in question were all in the WSUS\UpdateServicesPackages directory, and are named according to the GUID of the update in WSUS. The WSUS console doesn’t provide any way to get a list of GUIDs that are valid updates, but you can do it using the WSUS .NET API, which is accessible via PowerShell.

Update: If you’re only interested in which folders to delete, without any additional information, you can run wsusutil listunreferencedpackagefolders from the %Program Files%\Update Services\Tools directory. This command is mysteriously missing from any online documentation from MS.

Here’s a sample script to get the GUIDs. You’ll need to customise line 2 to reflect the FQDN of your WSUS server, along with whether to use SSL and the port number. You’ll either need to run the script using an account with admin rights to WSUS, either on the WSUS server itself, or on a workstation with the WSUS console installed.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer('updates.angrytech.internal',$False,80)
#Get all updates
$updates = $wsus.GetUpdates()
#Iterate every update and output some basic info about it
ForEach ($update in $updates) {
New-Object PSObject -Property @{
Id = $update.Id.UpdateId.ToString()
Title = $update.Title
Source = $update.UpdateSource.ToString()
}
}

(With thanks to Boe Prox’s excellent series of articles on managing WSUS with PowerShell)

This will spit out a (very long) list of every update update GUID on the server, the source of the update (either MicrosoftUpdate or Other for local packages), and its Title (which will probably be truncated).

How you then use this list is up to you, but I went with importing it into Excel, then using VLOOKUP with a list of folders that were on the server and seeing which folders matched up to updates and which didn’t. If I had taken the time I could have automated the whole thing, but I chose not to because I wanted to manually check the contents of each folder anyway before deleting it. Whatever method you choose, do so at your own risk.

In all, I found more than 8GB of orphaned files spread across more than 70 packages that I had previously removed from the SCE console over the last year. That amounted to nearly 20% of the total space used by WSUS, so we’re not talking about small amounts of wastage here.

The TechNet post I mentioned above is from nearly 3 years ago, and originally referred to SCE 2007. That this bug hasn’t been fixed after 3 years and a whole major version later is frankly pitiful.

How to create Exchange Mail Users in bulk using ‘Enable-MailUser’, you idiots

First things first: Mail Users are NOT Mailbox Users. This is a fundamental mixup that inattentive morons seem to frequently fall foul of on Exchange forums. Creating Mailbox Users, being users who have a mailbox in your Exchange organisation, is so easy to do in bulk that it’s even in the Exchange Management Console GUI, so there’s no point in me or anyone else explaining how to do it.

Mail Users, on the other hand, are users that exist in Exchange but have an external address and no mailbox in your organisation. Unlike a Mail Contact, however, this user has an AD account in your forest. Creating these in bulk is a bit trickier and very badly documented. The reason probably stems from the fact that a) the Exchange developers hate anyone without an Exchange mailbox, and b) that the underlying PowerShell commands in Exchange 2007/2010 do not work the same way. And let’s face it, as much as I prefer a GUI for almost any admin task (due to not being a pretentious masochist), the Exchange Management Console is really just a front end for PowerShell.

No, a single line of PowerShell to do this is simply out of our reach. For this, we have to resort to… TWO WHOLE LINES of PowerShell:

$enableusers = Get-User -Filter {Department -Like "8*" -And RecipientType -eq "User"}
$enableusers | foreach { Enable-MailUser $_ -externalEmailAddress "$($_.name)@angrytech.com" }

This is the code I used today to automatically add mail users for all my Year 8 students (whose Department field in AD is filled in with their form, i.e. “8B”). There are plenty of other fields you can filter on. The first line retrieves the list of users, deliberately only picking User objects (not MailUser) to avoid trying to add a mail user twice. The result set of this is then enumerated by Enable-MailUser on the second line, specifying that the external email address should be made up of the AD users common name (CN) with @angrytech.com on the end, which is their (fake) email address on Google Apps.

If you already have email addresses filled in on the AD objects, and simply want to reuse this data, the second line would be as follows:

$enableusers | foreach { Enable-MailUser $_ -externalEmailAddress $_.WindowsEmailAddress.toString() }

And that’s how you get around the fact that the Exchange developers were too sodding lazy to have multiple Mail User creation in the EMC.

I still don’t like PowerShell.