monad.exe backup exec 2010 and failed exchange GRT backups

I got this one from a colleague this week who'd been struggling with a backup exec issue. GRT enabled exchange backups suddenly stopped working and the event logs on the exchange server kept showing a monad.exe 13.0.4164.0 failure followed by beremote crashing. Symantec released a hotfix this week that appears to fix it:

http://www.symantec.com/business/support/index?page=content&id=TECH148347

Dell WebCam and WebEx problem

I recently had fun trying to get the integrated Dell WebCam on an E6410 to work with WebEx. Turns out that by default the software runs in Capture mode. At the bottom right if you change the drop down to IM mode, then WebEx can use the camera.

How to Set Up AD FS 2.0 to SSO to Salesforce using SAML 2.0

Project:

Set up Microsoft AD FS 2.0 on my Windows 2008 R2 Active Directory to allow my users to authenticate to Salesforce.com using their domain accounts using SAML 2.0. We'll be using Federated Authentication and not delegated authentication which requires you to code your own web service.

Introduction:

On paper, Single Sign-On (SSO) looks fairly simple and very logical and can lull you into a false sense of confidence. In practice, it requires a lot of planning, preparation, and some knowledge of sessions, authentication infrastructure, packet capture, encryption, and sometimes alcohol. If you're more of an administrator and less of a programmer, you'll also notice how closely the lines between the two are blurred when you work with these products. There's a lot of articles out there on using several 3rd party IDPs to SSO to the force.com suite but I had trouble finding stuff for AD FS 2.0

Prerequisites:

A working Active Directory, preferably 2008 or higher.

A server or virtual machine that can run AD FS 2.0, preferably 2008 or higher and joined to your domain.

An active Salesforce.com account. They do recommend using a developer account for the initial setup and testing of SSO.

A valid SSL certificate that's trusted on the Internet. I use a wildcard certificate personally.

A DNS host record for your new AD FS. For this tutorial, I'm using samlportal.example.com

If you're using a firewall (which you should) between your AD FS and the internet, then you'll need to publish inbound SSL to it. Preferably with no authentication required.

If you want to set up a AD FS Proxy in a DMZ, then a second server or virtual machine will be required. For that, you'll need port 443 open from the proxy AD FS to the internal AD FS and 443 open from the internet to your proxy AD FS. The proxy server does NOT have to be domain joined.

Federation Service Name notes:

Try to avoid using your internal DNS AD name, and do not name it the same as the server's host name. You really want this name to be unique. This name will also have to be resolvable on the Internet since you'll need an A record for it and an SSL certificate.

Setup:

First download AD FS 2.0 to your server.

Install the IIS role on your server.

Add your SSL certificate to IIS (IIS manager under Server Certificates) and bind it to 443.

Test the server to make sure SSL is working.

Only AFTER you have the SSL settings right, then proceed to install AD FS 2.0

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en

Install AD FS 2.0 and choose the "Federation Server" option.

Then run the AD FS 2.0 Federation Server Configuration Wizard to Create a new Federation Service.

Now you have a decision point, if you've only got a handful of users you can just do a stand-alone install. If you plan on having hundreds to thousands of users on this, then you can set up a Farm which will allow you to have multiple servers. Note: This option uses Windows Internal database (aka SQL express effectively). If you want to utilize an existing SQL DB server, you have to install using the command line.

Next the installer will detect your SSL certificate. If it doesn't, something's wrong with your IIS configurations.

Click Next

It'll install now and give you a list of success/failures. Warnings are generally not a problem and often occur if you're reinstalling AD FS.

If you get an SPN registration error, you'll have to update it manually from the command line. Substitute the following using your federation id and the account you're running AD FS as a service under.

setspn -S host//samlportal.example.com ADFSserviceAcctName

After that's done, go into the AD FS 2.0 console, click Service, right click on Service and choose Edit Federation Service Properties.

Confirm that the Federation Service name, etc all match what you have on your DNS A record and your SSL certificate. Copy down your Federation Service Identifier.

Then go under Certificates and Export a copy of your Token-signing certificate. Now we'll jump over to Salesforce as we can't proceed without data from them.

Next go into your salesforce account, then Setup, then on the left Security Controls, then Single Sign-On settings. This next bit of configuration came from a forum post from "Da G Man" on the thread: http://social.msdn.microsoft.com/Forums/en/Geneva/thread/2fc66b27-966c-49e5-891e-6e7e404e001d (Yeah, forums are great).

Choose Edit, then change the SAML drop down to 2.0.

For the Issuer, enter in your Federation Service Identifier. In this example, it was http://samlportal.example.com/adfs/services/trust

And yes, that is http and not https. And it is CASE-Senstive.

Choose User ID Type: Assertion contains User's salesforce.com username

Choose User ID Location: User ID is an Attribute element.

Enter Attribute Name: mail

Then click Save.

Now you can click on the Download Metadata button. Copy this file to your AD FS server.

Next on your AD FS server, go to Trust Relationships>Relying Party Trusts and add a new Relying Party Trust.

Under Data Source, choose Import data about the relying party from a file and choose your file that you downloaded from Salesforce.

Name it something. (This name will display on your user's login portal)

Choose the Permit all users option.

Click Next.

Click Finish.

Right-click on the relying party trust and choose Edit Claim Rules.

Name the claim something.

Choose Active Directory for the Attribute Store.

Choose E-mail Addresses for the LDAP Attribute and type in mail for the Outgoing claim Type.

Click OK, then OK.

Now make sure you have a user in salesforce whose username field matches the primary email address of a user in your active directory. Also make sure that this user is not an Administrator in Salesforce as by policy SSO supposedly doesn't work for those.

Now it's time to test. After much searching I figured out what URL I was supposed to use and I've provided it below:

https://samlportal.example.com/adfs/ls/IDPInitiatedSignOn.aspx

(yes, it is https and it has no bearing on your Federation service identifier being http)

The picture above is from a Microsoft doc on AD FS. http://download.microsoft.com/documents/France/Interop/2010/Using_ADFS2_0_For_Interoperable_SAML_2_0-Based_Federated_SSO.docx

At this point the IDPInitiatedSignOn page should have loaded. If it didn't, then you've got a configuration issue. Otherwise you should be at a page that gives you the option to either log on or log on and go to salesforce in one step.

So now you've (hopefully) got the IDP initiated sign on part working! At some point you'll notice that you're still able to log in with your old login and password if you go to the salesforce site directly. Apparently the only way to fix that is to first switch to using their My Domain feature.

Once you're provisioned your domain, then log off, then back on using your new domain URL which will be in the form of yourdomain.my.salesforce.com

After that's set up, if you go back into Single Sign-On Settings and enter in an Identity Provider Login URL and Save your site will now force all visitors to use Single Sign-On. Now the URL is tricky and I found one that works but I can't promise it's the 'correct' one but it works and that'll do for now.

https://samlportal.example.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://yourdomain.my.salesforce.com

The above URL is comprised of my my SSO provider's IDP signon page plus a '?" then loginToRp= and then your salesforce domain name.

For further troubleshooting you may want to install a header capture program like Fiddler to help you debug your setup.

Feel free to comment if you have any corrections or suggestions and I'll integrate them into this howto.

Additional Notes:

There's a fun bug in Firefox where it'll prompt you endlessly for credentials. Workaround is here:

http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx

If you want to provide the Identity Provider Logout URL you can use:

https://samlportal.example.com/adfs/ls/?wa=wsignout1.0 (yeah, it's a legacy method but seems to work)

Useful Links:

Good forum post that answers the my domain SSO question.

http://forums.sforce.com/t5/Security/SSO-Federated-Authentication-Help-needed/m-p/183606#M154

http://wiki.developerforce.com/index.php/Single_Sign-On_with_SAML_on_Force.com

https://login.salesforce.com/help/doc/en/sso_saml_login_history.htm

http://wiki.developerforce.com/index.php/How_to_Implement_Single_Sign-On_with_Force.com

Changing Federation Service Name.

http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-how-to-change-the-federation-service-name.aspx

Powershell - search folder hierarchy for names matching a pattern from a file and copy them.

So I had a request this week for a quick script that could search a folder structure for filenames for patterns that matched strings inside of a text file and then copy them to another folder. All the files had long complicated filenames so they needed an easy way to search through them. If it was *nix I'd just use Perl but since it was for Windows Powershell's the right way to go.

the text file contained strings like

00xy569e

TRs3002010

00xy589f

00xy589s

# Gnawgnu - 2/2011

# Searches filenames in a folder structure for

# patterns provided via text file

# Files to be Searched.

$srcFolder = "D:\filestobesearched"

# Destination of file copy.

$dest = "d:\CopyMatchesHere"

# List of patterns to look for.

$srcFile = "d:\matchlist.txt"

# Read in matchlist from text file.

$matchlist = Get-Content $srcFile

foreach ($match in $matchlist) {

$a = gci -r -i *$match* $srcFolder

foreach ($c in $a) {

# Change to move-item if needed

copy-item $c $dest

}

}

How to survive installing Exchange 2010 SP1

In recent years Microsoft, in my opinion, has generally gotten better at putting out service packs that don't cause massive failures. So I was a bit surprised when I saw how many people were having problems with the latest Exchange 2010 service pack. I actually put it off for an extra month after reading some of the forum posts. But this week I revisited it and was able to deploy SP1 on my exchange servers without any hitches.

My usual process for getting ready for an upgrade is to read every forum and blog post about it I can find and to start looking for patterns of what people are running and where they're running into issues. The most useful site I used this time was:
http://msexchangeteam.com/archive/2010/09/01/456094.aspx
After all, no better place to start than a blog run by Microsoft Dev's.

I wasn't very pleased to find that only 1 of the pre-requisite patches I needed was a general release. The others were all what most of us would call beta or pre-release patches but MS swears up and down these have been fully testing and vetted. (Overall still not much comfort when you're installing them on your production servers.)
For my Windows 2008 R2 x64 servers I installed:
979099
982867
983440
981002
979744 - (watch out for an error that pops up for some people who have multiple iis bindings.)

And then I installed the Microsoft Filter Pack 2.0 which was recommended on another forum. Then I rebooted and took a backup of the server.

Then just prior to installing the patch, I stopped these services as recommended in this post:
http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/7c19d906-35ef-4053-bb64-f5a2cab4c008

Exchange Transport Service
System Attendant
Information Store

I also turned off my antivirus program and symantec spam filter.

I then extracted the SP1 patch and then ran setup on my CAS server as a user that had rights to update the domain schema and crossed my fingers. I was pleasantly surprised when it completed without any errors and tested it out to make sure it was working alright.

Then a couple of days later I went ahead and updated the Hub Transport/Mailbox server using the same procedure. So far everything's working fine. Next I'll work on converting my Managed Folder policies to the newer Retention Tag system.

Finally, an electronic switch hook for my plantronics/nortel ip phone.

Since we started rolling out the Nortel IP 200x phones and now the Avaya 11xxe series phones the biggest complaint we've had from our users is that the HL10 lifter from Plantronics keeps falling off. Thankfully, Plantronics has recently released a series of USB EHS devices to integrate existing CS55 and CS70 headsets into our Avaya 1120e IP Phones.

My test configuration:
1. Avaya 1120e
2. APU-7 EHS Cable from Plantronics
3. CS70 headset

Tests:
1. Called into the IP Phone - confirmed that I received a ring warning through the headset
2. Pick up incoming phone call using button on headset - success
3. Turn on headset and get dial tone - success

Sadly, though, they missed one important feature with the new EHS cables - they didn't give us any way to hook up an online indicator light. On the old HL10 it was easy to hook one up but that feature got lost on this new device. Other than that this is a great new solution for us and I won't miss having to deal with all the wiring and points of failure that came with the HL10.

Cisco SLM2008 web managed and STP capable switch review

So I've finally got a solution for my conference room switches. Every once in a while a bonehead user will plug both ends of a cable into the switch and take out a section of the network (STP convergence times heading toward infinity tend to have a detrimental effect on uptime). The larger switches all have Spanning Tree Protocol set up on them so they weren't really affected but I didn't have a cost effective solution for the smaller rooms that needed switches; and preferably the type that don't howl or cost a fortune. Enter in the Cisco Small business smart switch series:
SLM2008 - http://www.cisco.com/en/US/products/ps9996/index.html
They're compact, web-managed, support STP, VLANs, and the 8 port gigabit model only costs $100.

So after having set it up I had to test the bonehead maneuver! As much as the effort went against my better instincts, I took a cable and plugged it into ports 1 and 4. As you can see below, the switch detected the loop and blocked the ports out, thus preventing a cascade of pain to the nearest network closet.



And that's just one less vulnerable flank on my network...

Seagate GoFlex - testing USB 2.0 vs eSATA performance

Recently I picked up some of the new Seagate FreeAgent GoFlex drives with the swappable interface dongles since we've had good luck with the previous generation of drives and we were interested in seeing if we could eek out a little bit more performance by changing interfaces for it. Running virtual machines off external hard drives is slow enough as it is so every 1MB/s you can get is a plus to me. My test platform was a Dell Latitude e6410 and a 500GB GoFlex drive with both the USB 2.0 and eSATA dongles.
First I tried out a few large file copies (500MB to 2GB) and noticed that windows was reporting a higher sustained rate for the USB2.0 but I also noticed a very long delay on the last 1-2% which I'm pretty sure was a cache delay. This delay at the end offset the perceived higher transfer rate that the USB transfer had shown. The eSATA transfers all went smoothly with no lag at the end at all. What can I say, I liked the honesty of the eSATA estimates better.
I then tried out some disk benchmarking tools like CrystalDiskMark (below) for further data and fortunately they all seemed to show the same significant advantage toward the eSATA:



Now I'm by no means an expert but I think eSATA will be the way to go for my Virtual Machines. At the very least the high sequential read/write should make the startup/shutdown for the VMs faster than they currently are under USB. So I shall sent out my little guinea pigs and wait for Murphy's law to kick in...