Quite a few years back, I realised that the FSP was good. In fact so goo,d that I pushed hard for a VM to host the FSP service, back when I was working with Config Manager 2007. Having visibility of deployment failures was an absolute boon. At least until I realised that there was noone to actually go and fix the problems that I found.
I guess sometimes people prefer just not to know…
Anyway, the annoying errors about not being able to contact a FSP in the ccmsetup.log were also dealt with. No more red lines. Hulk happy.
One thing to bear in mind with the FSP is that it will, by design, accept unauthenticated traffic. Having a FSP increases your attack profile, so be wary. I’d strongly advise against doing what an erstwhile colleague of mine suggested and dropping the role on your primary site server xD
However there was a drawback, and this persists to Config Manager 2012.
If a PC is disposed of and has reported a deployment failure to the FSP, it remains on the FSP report even if it is removed from Config Manager. For example, an old desktop fails to install the client, and reports to the FSP a client deployment failure. This entry will now remain, seemingly in perpetuity.
I had PCs listed as deployment failures that were most likely rotting away in a Chinese landfill; they had not been near the site for months, if not years, yet the FSP still reported on them.
I queried this on TechNet but didn’t get anywhere.
So I cultivated my own, albeit cackhanded, solution. I took advantage of lax security around the FSP, and spoofed a successful install.
I booted up a trusty old XP VM and made sure there was no config manager client installed. I removed it from the domain, and then renamed it to a machine I wanted off the FSP deployment failure report. I then joined it back to the domain, and ran a client install. The logs reported a success, and within an hour, the bad entry was gone from the FSP. Huzzah.
I then removed the PC from the domain, uninstalled the client and renamed it in preparation for use again.