With ever increasing amounts of spam and spear phishing attacks, many companies today are going out of their way to warn users when an email is received from an external, and potentially unsafe, source. Thankfully the Exchange Management Console makes it fairly straight forward to create transport rules to add disclaimers, re-write subject lines, and even insert html into emails for all types of situations.
Recently I was asked to add an [EXTERNAL] tag to the subject line of all incoming emails from outside the organization. Below are the steps to create a Hub Transport rule to accomplish such a task.
- Open the Exchange Management Console
- Navigate to Organization Configuration -> Hub Transport
- On the right side of the console click “New Transport Rule…“
- The New Transport Rule wizard will open. Simply follow the onscreen instructions, entering a name and comment for the rule. Click Next when finished.
- Under Conditions, select “from users that are inside or outside the organization” and “sent to users that are inside or outside the organization, or partners.” Click the blue links under Step 2 to change the from users field to “Outside” and the sent to users field to “Inside.” Click Next when completed.
- Under actions, check “prepend message subject with string.” Click the blue link next to “string” to edit the subject prefix. Enter the tag that you’d like to appear in the subject line. Click OK and Next.
- Under Exceptions click “except when the Subject field matches text patterns.” Click the blue link next to “string” and added the same prefix you added in the previous step. This will prevent multiple subject stamping from occurring when people email back and forth. Click Next.
- Click New to create your new transport rule.
- Emails from an external source should now have a new tag in the subject line.
While setting up the new GNS3 1.4 Virtual Machine with VMware Workstation 12 Player, I ran into an interesting error that was preventing me from completing the installation.
Thankfully the fix is fairly straight forward and requires that we edit the VMware Workstation preferences file.
- Open preferences.ini in your text editor of choice
- Add or edit the following line, changing the path to where your virtual machines are stored
prefvmx.defaultVMPath = "C:\Path\To\My\VMs"
- And that’s it. Save the ini and restart the GNS3 Setup Wizard.
Credit to the VMware support forums: https://communities.vmware.com/thread/245114?start=0&tstart=0
After following the Prime Infrastructure upgrade path to 2.2 you’ll need to re-issue CA signed certificates. Unfortunately, this can’t be accomplished from the Web GUI and will need to be done via the CLI.
Here’s Cisco’s documentation for installing CA-Signed Certificates and the steps I used to import a new certificate from our Active Directory Certificate Services server.
- First you’ll want to SSH to your Prime Infrastructure server as well as create a FTP server on your workstation. See my previous blog post for instructions how to do so.
- Generate a new CSR file and answer the information prompts
PIServer/admin# ncs key genkey -newdn -csr CSRFile .csr repository defaultRepo
The NCS server is running. Changes will take affect on the next server restart
Enter the domain name of the server: (the fqdn you'll use to access prime from e.g., prime.company.org)
Enter the name of your organizational unit:
Enter the name of your organization:
Enter the name of your city or locality:
Enter the name of your state or province:
Enter the two letter code for your country:
Generating RSA key
- Copy the CSR to your FTP server
PIServer/admin# copy disk: /defaultRepo/ CSRFile.csr ftp://your.ftp.server
- Open your CSR in a text editor, copying the text to your clipboard
- Navigate to your internal CA and click Request a certificate
- Click Submit an advanced certificate request
- Under “Saved Request,”paste your certificate request output from earlier and select the Web Server certificate template. Click Submit
- Download your certificate and copy it to your FTP server directory
- Copy the certificate from the FTP server to the default repository
PIServer/admin# copy ftp://your.ftp.server/CertFile.cer disk:defaultRepo
- Import the certificate into the Prime Infrastructure server
PIServer/admin# ncs key importsignedcert CertFile.cer repository defaultRepo
- Restart Prime Infrastructure
- When the server comes back up, reload the web page and you should notice that the site is now trusted!
At the moment we’re running Cisco Prime Infrastructure 2.1 on a Gen1 physical appliance. We’re looking to take the upgrade path from 2.1 all the way up to 3.1 (currently only 3.0.2 is supported on the Gen1 appliance).
First stop, 2.2.
The Gen1 appliance upgrade path isn’t a fun one. It requires that we back up our current application database, wipe our appliance, do a bare-metal install of 2.2, and then restore our application database. Cisco’s documentation for application backup and restore can be found here: http://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/2-2/administrator/guide/PIAdminBook/backup_restore.html#72460
Back up the PI application database to an FTP repository (I recommend FileZilla Server for hosting a light-weight FTP server on your workstation).
- Create a ftp repository on your Prime Infrastructure server via CLI
- SSH to PI
user username password plain password
- Verify your repository configuration
- Backup your Prime Infrastructure application
backup backup-name repository repository-name application NCS
Install Prime Infrastructure 2.2
Reboot your appliance from the PI 2.2 installation media and follow the on-screen configuration prompts. For more information follow Cisco’s Installation Guide
Restore your application database
- SSH to the Prime Infrastructure server and setup your ftp repository again
user username password plain password
- Verify your repository configuration, and check that your backup is there
- Run the restore command, taking note of the scary warnings
restore BACKUP_NAME.tar.gpg repository REPOSITORY_NAME application NCS
After running February 2016’s batch of Microsoft security updates, we started receiving calls from end users about errors when attempting to update their passwords through the Citrix web interface.
While the error indicates the password change failed, it does in fact work, and users can log out and log back in with the new password.
Thankfully it didn’t take long for some savvy Citrix support forums users to pinpoint the issue to a recent patch Microsoft released which changes the api behavior for NetUserChangePassword.
Uninstalling patches KB3126587 or KB3126593 from your Citrix XML brokers will resolve the issue, but on March 8th 2016, Microsoft released a security update which addresses the problem.
Simply install the new patch on your XML brokers –which does require a reboot!– and you should be good to go.
See Citrix’s updated support article below, along with Microsoft’s patch information.