Home > Microsoft Forefront Security > A few tips on installing Microsoft Forefront Client Security

A few tips on installing Microsoft Forefront Client Security

We decided to try out Microsoft Forefront Client Security, since we get free licenses, and it’s time to end the hodgepdge of third-party antivirus apps we have. Once again, Microsoft has proven to me “the Linux lesson”: just because the software license is free, does not mean that my time working with a cranky system is cheaper than buying something better. In this case, it took me over a week to get it installed! Here are a few of the pitfalls I ran into along the way:

  • It will not install on Windows 2008 R2.
  • It will not install on 64 bit Windows.
  • It is not compatable with SQL Server 2008; only SQL Server 2005.
  • SSRS (SQL Server Reporting Services) is still a pain in the neck to install and get working right. On Windows 2008, you need to go into the IIS Management Console, select the “ReportServer” application for the installation, click “Handler Mappings” and then “Edit Feature Permissions” and enable “Script” and “Execute”. This is the hidden, undocumented trick.
  • The “Distribution Server” will not install on 64 bit Windows either, but that’s OK if you have an existing WSUS 3.X install, since that can handle the definition updates. You’ll need to manually deploy (or use SCCM) the client yourself in that scenario, though.

Yes, I basically tried every permutation of Windows 2008, 32 and 64 bit, and SQL Server (the requirements documentation is not very clear on most of this, other than the 32 bit requirement which I overlooked) until I finally got this thing installed.

I haven’t gotten to use it yet, but given the installation nightmare, I already strongly prefer TrendMicro which I had great success with a few years ago.

J.Ja

Categories: Microsoft Forefront Security Tags:
  1. December 8th, 2009 at 09:05 | #1

    So, what is this adjunct software doing for you?
    Isn’t Windows secure enough by itself?

  2. December 8th, 2009 at 09:21 | #2

    Dietrich Schmitz :

    So, what is this adjunct software doing for you?
    Isn’t Windows secure enough by itself?

    LOL, Windows would be, if I didn’t have users that bring in anything and everything from home, on a USB drive, and then run it… or if I didn’t have users that, for historical reasons, are running as local administrator and I can’t do a thing about it. It will take 2 – 5 more years to get those folks weaned off of the local administrator bottle, if you know what I mean. I have to wait until a million various “utility machines” get replaced. Even then, they install all sorts of weird application which I have little/no control over. It’s a very unusual setup we have. Let’s just say that a lot of the PCs are dual purposed for explicit “daily work” purposes and special purposes, and the special purpose needs (which are explicitly approved by management) are what cause me the problems.

    J.Ja

  3. December 8th, 2009 at 09:49 | #3

    @Justin James
    Ah, I see. It’s the users’ fault. Not Windows. Right? Righhhhhht. ;)

  4. December 8th, 2009 at 10:29 | #4

    Dietrich Schmitz :

    @Justin James
    Ah, I see. It’s the users’ fault. Not Windows. Right? Righhhhhht. ;)

    In this case, yes. If I ran a Unix system like this, it would be just as wide open to attacks as Windows. You can’t have users doing daily business with full admin privs and expect the system to stay secure, *regardless* of platform. Indeed, it would be considered a “bug” if the exploits didn’t work when run as an admin user.

    And it’s not *entirely* the user’s fault. It’s also the fault of their stupid applications and the programmers who wrote them. Microsoft has been putting out guidelines about this stuff since around NT 4. App developers refused to go along with it, so they put UAC in place which “broke” the apps that had refused to comply with the guidelines that have been around for 10 years. It’s rediculous.

    J.Ja

  5. December 8th, 2009 at 10:57 | #5

    Well, I don’t see the equivalence. Sorry. Don’t buy your argument.
    Users get whatever you delegate via sudo.

    Giving out Admin rights on Windows to ‘alleviate’ configuration/support issues is just symptomatic of a larger underlying problem with Windows being a single-user system adapted to the multi-user world.

    Unix/GNU/Linux are multi-user platforms from the ground up.

  6. December 8th, 2009 at 11:24 | #6

    Dietrich Schmitz :

    Well, I don’t see the equivalence. Sorry. Don’t buy your argument.
    Users get whatever you delegate via sudo.

    Giving out Admin rights on Windows to ‘alleviate’ configuration/support issues is just symptomatic of a larger underlying problem with Windows being a single-user system adapted to the multi-user world.

    Unix/GNU/Linux are multi-user platforms from the ground up.

    No clue why you don’t see the equivalence. Handing out users the root password to a Unix box and telling them to login with that “to make life easier” is just as dumb and deadly as making Windows users local admins. It’s 100% equivalent.

    And you are really missing the point with the Windows security situation. The problem comes about *precisely* because Windows has some pretty strict seperation of privledges for users now. The problem is *application developers* who refuse to take a look at how they write code, and make sure they play nice.

    Look, if a bunch of *Nix application out there demanded that it be run as root, because they all were written to, say, use /local/lib as a temporary directory for some reason, would you be blaming *Nix architecture, or the applications? The applications, of course. And that’s the Windows problem. App developers are just not getting the message about things like, “no, you don’t need to write to the global machine registry for your configuration” and “no, you do not need to dump DLLs into C:\Windows\System32″ and so on. The situation has gotten a LOT better, thanks to .NET though. With .NET, it is very easy to do things the right way, and very tough to do them the wrong way.

    J.Ja

    J.Ja

  7. December 8th, 2009 at 11:57 | #7

    Bad analogy because nobody hands out the root password on Unix, GNU/Linux systems, unless they plan on being summarily dismissed.

    You delegate via sudo to individuals for select tasks or with group membership but not handing over root.

    Sorry, you argument doesn’t hold water.

  8. December 8th, 2009 at 12:24 | #8

    Dietrich Schmitz :

    Bad analogy because nobody hands out the root password on Unix, GNU/Linux systems, unless they plan on being summarily dismissed.

    You delegate via sudo to individuals for select tasks or with group membership but not handing over root.

    Sorry, you argument doesn’t hold water.

    Sorry, but you are failing to see my point. I am not saying that anyone would hand out the root password on *Nix. I agree, it’s INSANE. What I *am* saying, is that due to decisions made by some application developers, their applications require full administrative privs to work. So, for these applications to be used, you have to perform the equivalent of giving the root account to users (the “Administrator” user does not have any special privs that putting someone in the “Administrators” group does not).

    Once again, this is not a defect in Windows, it is a defect in the applications. Too many of them demand full privs, even if they do not actually need them, in order to operate.

    I may add, the UAC system is similar (by no means identical) to sudo in that it requests permission on a per-task basis.

    At this point, I am not making any kind of arguement. I am simply laying out some facts for you, since you do not seem to understand the full scope of the problem. It is simple to go along with the “common sense” that the Windows architecture is all wrong. And yes, there are some underlying issues with it, like the backdoors that exist for “Genuine Windows Validation” to work. But to say, “gee, the existence of viruses and security holes on Windows shows that it is a piece of junk” is foolish. Mac OSX is riddled with security holes, depite being built on top of BSD, which is a well regarded system when it comes to security. Every OS has its problems. The big problem with Windows at this time, is that application developers keep working like it’s 1989 or 1999, not 2009, and write code that acts like it owns the system. As a result, users often end up in a position to own the system, because it’s the only way to usefully use certain applications. That being said, UAC has proven to be such an impediment to using these application without breaking into tears, that it has finally forced application developers to follow the rules that were in place but unenforced for over 10 years.

    J.Ja

  9. nucrash
    December 8th, 2009 at 12:41 | #9

    I think an easier lesson would be to just setup users as “users” by default. Unfortunately every admin I know still uses the default for setting up new users. This gets to be even more exciting on Novell Networks.

    My biggest issue is that I shouldn’t have this problem. I tried to combat this years ago and was swatted down by other admins saying that trying to have users run as users was simply too difficult.

  10. December 8th, 2009 at 17:18 | #10

    nucrash :

    I think an easier lesson would be to just setup users as “users” by default. Unfortunately every admin I know still uses the default for setting up new users. This gets to be even more exciting on Novell Networks.

    My biggest issue is that I shouldn’t have this problem. I tried to combat this years ago and was swatted down by other admins saying that trying to have users run as users was simply too difficult.

    Setting up users as non-admin by default is easy, it’s the default. Where it becomes a hassle, is when every 10 minutes they need an admin to install an application. It’s a cultural issue that is very difficult to address. :(

    J.Ja

  11. AdamR
    December 29th, 2009 at 11:15 | #11

    I hadn’t noticed before (wasn’t sure if you had), but there’s a \client\x64 directory which seemed to install onto my Windows Server 2008 x64 (not R2). I ran the clientsetup.exe through the command prompt, so I’m not sure if the autorun GUI decides 32 vs 64 bit or just fails w/ 32bit.

  12. January 6th, 2010 at 08:08 | #12

    @AdamR

    Good question, I’d be pretty sure that it is smart enough to do the autodetect.

    J.Ja

  13. Yes It Runs On 64bit
    August 8th, 2010 at 05:19 | #13

    It does run on 64bit

  14. Yes It Runs On 64bit
    August 8th, 2010 at 05:25 | #14

    @AdamR
    Try to run clientsetup.exe using commandline with switches by opening an elevated (Administrators rights) shell (DOS), like this:
    c:\somefolderwhereyougotthesoftware>clientsetup /NOMOM

    or follow this site for more instructions
    http://portal.sivarajan.com/2010/05/installing-forefront-client-security.html

  1. No trackbacks yet.