This blog article will briefly describe the new URL filtering features in the updated AsyncOS 8.5.0 for the Cisco IronPort Email Security Appliance.
Before you upgrade to 8.5.5 (which is the latest OS as of this post), please check the upgrade path at the URL below:
http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-5-5/ESA_8-5-5_Release_Notes.pdf
This will be a quick how-to guide on removing old/stale ActiveSync devices from Microsoft Exchange.
Note 1: I have only run this on an on-premises Exchange 2007 server so I am not sure if it will work in 2010, 2013 or Office 365 but hopefully the script will come in handy anyway
Note 2: This is my first ever PowerShell script so I am sure there are better ways of doing this but it does the job!
Okay so if you want to run a report on old devices (I have defined old as no successful sync in the past 30 days but you can change this to whatever you want) before you go ahead and remove them, run the following command:
Get-Mailbox | ForEach {Get-ActiveSyncDeviceStatistics -Mailbox:$_.Identity} | where {$_.LastSuccessSync -lt ((Get-Date).AddDays(-30))}
To actually remove these devices (this command removes the relationship between the device and Exchange – it will NOT wipe the device) run this command:
# Assign the full identity string for each of the old devices to the $staleDevices variable - this identity string is required for the Remove-ActiveSyncDevice cmdlet
$staleDevices = Get-Mailbox | ForEach {Get-ActiveSyncDeviceStatistics -Mailbox:$_.Identity} | where {$_.LastSuccessSync -lt ((Get-Date).AddDays(-30))} | select -expand Identity
# Loop through the identities and pass them in to Remove-ActiveSyncDevice. The -confirm at the end forces the command to go through. Remove it if you want to manually confirm each removal
foreach ($device in $staleDevices) {Remove-ActiveSyncDevice -Identity $device -confirm:$false}
This quick guide will show you how you can add and modify headers in Fiddler and them to all requests.
There will be times where you will need to test performance or functionality of web apps which may require the modification of request headers – for example, if you were to move to a shared hosting environment and want to test the functionality and performance of the new host without changing DNS records, you will need to modify the HOST header otherwise the host will not know which site you want to visit.
This will be a quick guide on configuring your Meraki Wireless Access Point to tag users in specific VLANs according to what AD group they are in.
In this example I will assume the following:
The Cisco Meraki range of products are really quite cool and changes the way you, as a sysadmin, think about network connectivity, management, troubleshooting and configuration in your organisation.
Meraki products are managed (almost) completely via Meraki’s Cloud Controller platform via the web. What this means is that 99% of the management can be done where-ever you have access to the internet; including the mobile app which in its current state, allows you to perform basic troubleshooting steps and analytics of the network.
That means you can be sitting at home whilst configuring your office network’s closet switches.
Any configuration changes made in the Meraki Cloud Controller (MCC) are immediately pushed down to the device via SSL as soon as the device has network connectivity. This means that you could even start configuring the devices as soon as you have ordered them, plug them in when they arrive and they will immediately fetch the config – in fact this is how I configured the access points I deployed at my organisation.
Also, an important note to make here – the Meraki range of products will continue to run on it’s existing config even if the product loses internet connectivity or is otherwise unable to contact the MCC.
The MCC interface is the heart of all config management, troubleshooting and network analytics. You can do a lot from this interface – from looking at Layer 7 application analytics per user to packet capture exports to scheduling over the air firmware updates. I definitely recommend looking at the training material as a lot of what I have said above is demonstrated graphically via webinars at the following URL:
https://meraki.cisco.com/webinars
In summary, I believe sysadmins need to watch this area for rapid development as I believe this type of management and deployment of network connectivity is only just the beginning of something very interesting.