Archive

Archive for January, 2011

TMG Basics – should we use this blog or a new one?

January 31st, 2011 Comments off

Hi all,

 

We thought it could be useful do create a series of blog posts about TMG basics (i.e. TMG 101). This would cover the different TMG features and concepts and walk people who are new to TMG through the first steps.

We thought of creating a new blog (called “TMG from the grounds up”) for these posts but we heard from a few people that they would rather that we post these articles in this blog (i.e. the TMG product team blog).

 

What do you prefer (please leave a comment)? Should we create a new blog, post to this one or both?

 

Thanks in advance for your feedback,

Ronit and Ori from the TMG team

Categories: Uncategorized Tags:

The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

January 29th, 2011 No comments

My last couple of posts have looked at the lighter side of blue screens by showing you how to customize their colors. Windows kernel mode code reliability has gotten better and better every release such that many never experience the infamous BSOD. But…(read more)

Categories: Uncategorized Tags:

Changing the FEP2010 Reporting Account

January 28th, 2011 Comments off

The FEP2010 Reporting account is defined during the FEP server setup, with the installation of the Reporting role to be exact.
The account is used by SQL Reporting Services (SRS) to access the FEP data source used by reporting. Incorrect credentials may result in an error as below or similar:

image

This post is to provide you with the steps needed to change the reporting account in the occasion you have a need to do so.

Note: all below steps must be executed with an administrator account.

Access to the FEP database used by reporting

These steps must be executed on the SQL Server hosting the data warehouse database (FEPDW_XXX, where XXX is your Configuration Manager site code).

  1. Open SQL Management Studio and select Database engine from the Server type list. Enter or browse the SQL Server name hosting the reporting database.
  2. Under the Security container in SQL Management Studio, right-click Logins and then click New Login.
  3. Enter the login name (including domain) for your new reporting account.
  4. On the left-hand side in the Page selection area, select User Mappings.
  5. On the right-hand side, select the FEPDW_XXX database.
  6. In the Database role membership area below, check AN_ReaderRole and then click OK.

Access to the OLAP cube

These steps must be executed on the SQL server hosting the data warehouse database (FEPDW_XXX, where XXX is your Configuration Manager site code).

  1. In SQL Management Studio, select Connect Object Explorer from the File menu.
  2. In the Connect to Server window, select Analysis Services from the Server type list.
  3. Expand the FEPDW_XXX database and the Roles container.
  4. Right-click the ReportsUserReadRole and click Properties.
  5. Click the Membership page on the right-hand side.
  6. Add your new reporting account if it is not listed on the right-hand pane by clicking the Add button.
  7. Remove the old reporting account from the list.

Change the account on the Reporting server

These steps can be executed from any system. XXX is your Configuration Manager site code.

  1. Open http://<reportserver>/reports (replace <reportserver> with the name of the report server).
  2. Click the Forefront Endpoint Protection_XXX link.
  3. Click the Show Details button in the top right.
  4. Click the DataSources link.
  5. Click the DefaultDataSource link
  6. Enter the credentials of the new reporting account and click Apply.

Update the reporting account in the registry

These steps must be executed on the server hosting the FEP2010 Reporting role.

  1. Open the registry editor on the reporting server.
  2. Navigate to HKLM\Software\Microsoft\Microsoft Forefront\Forefront Endpoint Protection 2010\Server
  3. Double-click REPORTUSER and enter the new reporting account (in the format domain\username).
  4. Close the registry editor.

Kurt Sarens, Senior Support Engineer

Forwarding on the 6to4 network interface cannot be enabled

January 28th, 2011 Comments off

An error you might run into when activating a DirectAccess configuration is the dreadful “Forwarding on the 6to4 network interface cannot be enabled”:

clip_image002

This often happens after you rebuild a server, and try to restore a configuration from backup, and is typically caused because of a duplicate 6to4 interface.

The first step of resolving this is to enable the interface manually, which is done this way:

1. Find the name of your 6to4 adapter by running the command netsh int ipv6 show int. This would often be “6to4 adapter”

clip_image004

2. Enable forwarding by running the command netsh int ipv6 set int <NAME> forwarding=enabled where <NAME> is what you found in step 1

clip_image006

Now, try activating DA again from the UAG console. You would probably be disappointed to see it fail again. If so, the reason is probably because the computer has duplicate 6to4 adapters, confusing the server. If so, you can easily fix this by removing the interfaces from the Device Manager:

1. Open Device Manager

2. Click View and select “View Hidden Devices”

clip_image008

3. Notice the two 6to4 adapters? There’s your problem. Remove both of them by right-clicking and selecting “uninstall”.

4. Close the device manager, and reboot the UAG server.

5. After a reboot, the 6to4 adapter will be re-added, but only once, so you should be good to go.

6. Activate the UAG configuration again, and this time, it should be fine!

Blog post written by Ben Ari

Categories: Uncategorized Tags:

Microsoft releases Security Advisory 2501696

January 28th, 2011 Comments off

Hello. Today we’re releasing Security
Advisory 2501696
, which describes
a publicly disclosed scripting vulnerability affecting all versions of
Microsoft Windows. The main impact of the vulnerability is unintended
information disclosure. We’re aware of published
information and proof-of-concept code that attempts to exploit this
vulnerability, but we haven’t seen any indications of active
exploitation.

The vulnerability lies in the
MHTML (MIME Encapsulation of Aggregate HTML) protocol handler, which is used by
applications to render certain kinds of documents. The impact of an attack on
the vulnerability would be similar to that of server-side cross-site-scripting
(XSS) vulnerabilities.  For instance, an
attacker could construct an HTML link designed to trigger a malicious script
and somehow convince the targeted user to click it. When the user clicked that
link, the malicious script would run on the user’s computer for the rest of the
current Internet Explorer session.  Such
a script might collect user information (eg., email), spoof content displayed
in the browser, or otherwise interfere with the user’s experience.

The workaround we are
recommending customers apply locks down the MHTML protocol and effectively
addresses the issue on the client system where it exists. We are providing a
Microsoft Fix-it package to further automate installation.

In our collaboration with other
service providers, we are looking for possible ways that they can take steps to
provide protection on the server side. Our Security Research & Defense team
has written a blog post that discusses some possible options.
However, due to the nature of the issue, the only workaround Microsoft can officially
recommend is what we have identified in the advisory. We will continue to work
closely with others in the industry and appreciate the collaboration we have had
to date.

We have initiated our Software
Security Incident Response Process (SSIRP)
to manage this issue. We’re also in
communication with other service providers to explain how the issue might
affect third-party Web sites and to collaborate on developing a variety of
further solutions that address the varied needs of all parts of the Internet ecosystem
– large sites, small sites, and all those who visit them.

Meanwhile, we are working on a security
update to address this vulnerability and we are monitoring the threat landscape
very closely. If the situation changes, we’ll post updates here on the MSRC
blog.

Thanks –

Angela Gunn
Trustworthy Computing

ISA Firewall Service Process (wspsrv.exe) high CPU utilization issue

January 26th, 2011 Comments off

1. Introduction

 

When dealing with ISA high CPU utilization where wspsrve.exe is the one consuming more resources, the first impression is that ISA is the culprit for that. There are some scenarios where this statement is true, such as this one that I documented last year. But there are other scenarios where this is not true, including scenarios where wspsrv.exe is crashing – not always is because of ISA itself. I tried to demystify this on this post that I wrote back in 2009.

 

This post is about a scenario where ISA Server was facing a 100% CPU utilization and wspsrv.exe process was consuming most part of that (around 93%). This was happening at least twice a day and the only way to get CPU get to a normal utilization was by restarting Firewall Service. Sounds like an ISA issue right? Not really and you will see.

 

2. Gathering Data

 

Use the same data gathering approach as the one listed in this post with an addition of getting a full memory dump using notmyfault tool, see KB972110 for more info.

 

3. Analyzing the Data

 

By reviewing perfmon data from the time that the issue was happen it was possible to see that wspsrv.exe was 88% average of CPU utilization, but notice that within this process there is no thread spending too much CPU cycles as shown below:

image

In order to better understand this issue we started to review the manual dump of wspsrv.exe process. By reviewing the user mode dump we were unable to determine what the root cause of the issue was. Most of the threads were waiting for something in Kernel mode as shown below:

 

> First step was to review the top threads that had calls in Kernel mode:

 

0:000> !runaway 7

 User Mode Time

… [hiding the values as they are not relevant here]

 Kernel Mode Time

  Thread       Time

  69:1310      0 days 0:00:49.500

  53:129c      0 days 0:00:46.812

 104:113c      0 days 0:00:42.390

  45:127c      0 days 0:00:40.875

  78:688       0 days 0:00:40.734

  94:4d0       0 days 0:00:38.890

 162:18a8      0 days 0:00:38.500

 166:18c8      0 days 0:00:38.093

 108:1418      0 days 0:00:37.062

 

> By taking a closer look into the threads we see that some of them are either performing RPC or DNS such as the one below:

 

0:000> ~104kb

ChildEBP RetAddr  Args to Child             

WARNING: Stack unwind information not available. Following frames may be wrong.

28cada54 77c7feb0 28cada90 28cada74 77c80845 ntdll!KiFastSystemCallRet

28cada60 77c80845 28cada90 76ed42d8 28cade84 rpcrt4!I_RpcSendReceive+0x23

28cada74 77ce415a 28cadabc 24b86ff4 00000000 rpcrt4!NdrSendReceive+0x28

28cade64 76ed5049 76ed42d8 76ed421c 28cade84 rpcrt4!NdrClientCall2+0x1a8

28cade7c 76ed4f69 00000000 29e2f078 00000001 dnsapi!NetInfo_Copy+0x5c2

28caded8 76ed6f5d 29e2f078 00000001 00000000 dnsapi!NetInfo_Copy+0x4e2

28cadf0c 76ee9d0c 00000003 28cae1d8 00000001 dnsapi!DnsValidateName_W+0x31f

28cadf34 62ea2cc4 28cae1d8 00000001 00000000 dnsapi!DnsQuery_A+0x20

28cadf78 62ea30a2 28cae1d8 00000001 28cadfb8 msphlpr!ProxyDnsCacheInit+0x52f

28cadf98 62ea217c 28cae1d8 28cadfb8 62ea1f0f msphlpr!ProxyDnsCacheInit+0x90d

28cae2dc 64760c2a 021d7710 28caeedc 00000001 msphlpr!ProxyGetHostByName+0x26d

28cae764 64761d11 28caeed4 00000400 28caee74 W3Filter!DllUnregisterServer+0x42ca6

28cae9d4 647638dc 28caeed4 00000400 28caee74 W3Filter!DllUnregisterServer+0x43d8d

28caf534 647295c7 00000000 00000000 28cafe14 W3Filter!DllUnregisterServer+0x45958

28caf554 647262ef 021d7008 00000000 000003e5 W3Filter!DllUnregisterServer+0xb643

28caf574 647277f8 28cafe14 00000000 00000001 W3Filter!DllUnregisterServer+0x836b

28caf590 647281c5 28cafe14 28038ce0 28038728 W3Filter!DllUnregisterServer+0x9874

28cafe1c 64728ad0 000000a7 00000000 0000000c W3Filter!DllUnregisterServer+0xa241

28cafe90 0046051a 28038728 00000001 00000000 W3Filter!DllUnregisterServer+0xab4c

28cafefc 0046032d 000000a7 00000000 00000001 wspsrv!SSL_CREDENTIALS::operator=+0x2a870

28caff20 00460bea 2685d018 004602b1 28caff50 wspsrv!SSL_CREDENTIALS::operator=+0x2a683

28caff30 00460266 000000a7 00000000 00000001 wspsrv!SSL_CREDENTIALS::operator=+0x2af40

28caff50 0044b0ff 2685d0bc 000000a7 00000000 wspsrv!SSL_CREDENTIALS::operator=+0x2a5bc

28caff7c 0044c08e 2685d0bc 000000a7 00000000 wspsrv!SSL_CREDENTIALS::operator=+0x15455

28caffb8 77e6482f 0000004f 00000000 00000000 wspsrv!SSL_CREDENTIALS::operator=+0x163e4

28caffec 00000000 0044bf26 0000004f 00000000 kernel32!GetModuleHandleA+0xdf

 

It was time to review the kernel dump file and verify if we had more information there:

 

> In this case we first started reviewing if there was anything locked in kernel space:

 

1: kd> !locks

**** DUMP OF ALL RESOURCE OBJECTS ****

KD: Scanning for held locks……………………………………………………

 

Resource @ 0x8a7f3008    Shared 1 owning threads

    Contention Count = 856651

    NumberOfExclusiveWaiters = 5

     Threads: 84149020-01<*>

     Threads Waiting On Exclusive Access:

              84166a80       8961d620       84166750       89649240      

              841777a0      

 

 

> Notice that we have 5 exclusive waiters wanting on a thread. Let’s see which thread is that:

 

1: kd> !thread 84149020

THREAD 84149020  Cid 1074.18a8  Teb: 7ff12000 Win32Thread: 00000000 READY

IRP List:

    fe5eae28: (0006,01d8) Flags: 00000884  Mdl: 00000000

    88bb1a68: (0006,01d8) Flags: 00000000  Mdl: 89128478

    fee50ba8: (0006,01d8) Flags: 00000000  Mdl: 880eb6c8

    f9d62af8: (0006,01d8) Flags: 00000000  Mdl: 887adee8

    fa284008: (0006,01d8) Flags: 00000000  Mdl: 87fb7bb8

    feb2dd80: (0006,01d8) Flags: 00000000  Mdl: 88bbdc48

    ff8c95f0: (0006,01d8) Flags: 00000000  Mdl: 88bbe488

    fac4b820: (0006,01d8) Flags: 00000000  Mdl: 8847d798

    fea1d008: (0006,01d8) Flags: 00000000  Mdl: 89252968

    ff097008: (0006,01d8) Flags: 00000000  Mdl: 8a5ee320

    fe64b008: (0006,01d8) Flags: 00000000  Mdl: 88a114a0

    feba1b30: (0006,01d8) Flags: 00000000  Mdl: 8975beb8

    ff499550: (0006,01d8) Flags: 00000000  Mdl: 87cd53a8

    ff5cf9f0: (0006,01d8) Flags: 00000000  Mdl: 8856dd18

    fc26ec38: (0006,01d8) Flags: 00000000  Mdl: 883df0a8

Not impersonating

DeviceMap                 e1750820

Owning Process            89f4ead8       Image:         wspsrv.exe

Wait Start TickCount      4518588        Ticks: 0

Context Switch Count      3718083            

UserTime                  00:01:15.546

KernelTime                00:01:02.906

Win32 Start Address 0x0044bf26

Start Address 0x77e617ec

Stack Init b7b39000 Current b7b38898 Base b7b39000 Limit b7b36000 Call 0

Priority 8 BasePriority 8 PriorityDecrement 0

ChildEBP RetAddr  Args to Child             

b7b388b0 8083d5b1 84149020 841490c8 00000000 nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])

b7b388dc 8083df9e 84149020 8a7f3008 00000000 nt!KiSwapThread+0x2e5 (FPO: [Non-Fpo])

b7b38924 8082e057 88f99718 0000001b 00000000 nt!KeWaitForSingleObject+0x346 (FPO: [Non-Fpo])

b7b3895c 80824ba8 89a0a400 00000000 8082c38e nt!ExpWaitForResource+0x30 (FPO: [Non-Fpo])

b7b3897c 8085110e 8a7f3008 00000001 b7b389d4 nt!ExAcquireResourceSharedLite+0xf5 (FPO: [Non-Fpo])

b7b3898c b9fb5c70 8a7f3008 89a0a400 00000000 nt!ExEnterCriticalRegionAndAcquireResourceShared+0x19 (FPO: [Non-Fpo])

b7b389d4 b9fb5b17 b7b38a18 b7b389ec 00000028 afd!AfdGetTransportInfo+0x1b (FPO: [Non-Fpo])

b7b389f0 b9fb5d9f b7b38a34 b7b38a18 00000000 afd!AfdAllocateEndpoint+0x1e (FPO: [Non-Fpo])

b7b38a38 b9fbf7a4 89b1e438 8a9a9f38 b7b38a5c afd!AfdCreate+0x13b (FPO: [Non-Fpo])

b7b38a48 80840153 8a9bc030 fe5eae28 fe5eae28 afd!AfdDispatch+0x79 (FPO: [Non-Fpo])

b7b38a5c 8092e87e b7b38c04 8a9bc018 00000000 nt!IofCallDriver+0x45 (FPO: [Non-Fpo])

b7b38b44 8092c3ea 8a9bc030 00000000 89062228 nt!IopParseDevice+0xa35 (FPO: [Non-Fpo])

b7b38bc4 8092d80d 00000000 b7b38c04 00000042 nt!ObpLookupObjectName+0x5b0 (FPO: [Non-Fpo])

b7b38c18 8092c6cd 00000000 00000000 dffa7c01 nt!ObOpenObjectByName+0xea (FPO: [Non-Fpo])

b7b38c94 80931d92 29b2f958 c0140000 29b2f90c nt!IopCreateFile+0x447 (FPO: [Non-Fpo])

b7b38cf0 8092fb28 29b2f958 c0140000 29b2f90c nt!IoCreateFile+0xa3 (FPO: [Non-Fpo])

b7b38d30 80833bef 29b2f958 c0140000 29b2f90c nt!NtCreateFile+0x30 (FPO: [Non-Fpo])

b7b38d30 7c82860c 29b2f958 c0140000 29b2f90c nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ b7b38d64)

WARNING: Frame IP not in any known module. Following frames may be wrong.

29b2f9ec 00000000 00000000 00000000 00000000 0x7c82860c

 

> This stack has a very good amount of IRPs (I/O Request Packet), let’s see if there is any pending IRP:

 

1: kd> !irp 88bb1a68

Irp is active with 4 stacks 2 is current (= 0x88bb1afc)

 Mdl=89128478: No System Buffer: Thread 84149020:  Irp stack trace. 

     cmd  flg cl Device   File     Completion-Context

 [  0, 0]   0  0 00000000 00000000 00000000-00000000   

 

                     Args: 00000000 00000000 00000000 00000000

>[  f, 8]   0 e1 8a94ddf0 870404b0 b9e964d0-870f66c8 Success Error Cancel pending

              \Driver\Tcpip*** ERROR: Module load completed but symbols could not be loaded for idmtdi.sys

       idmtdi

                     Args: 0000127b 00010020 00000000 00000000

 [  f, 8]   0 e0 8a85d020 870404b0 b9fc1b72-833955a0 Success Error Cancel

              \Driver\IDMTDI      afd!AfdRestartBufferReceiveWithUserIrp

                     Args: 0000127b 00010020 00000000 00000000

 [  e, 5]   5  0 8a9bc030 8583a190 00000000-00000000   

              \Driver\AFD

                     Args: 0000127b 00000000 20000020 00000000

 

 

> Notice that there is a third party transport driver interface (idmtdi.sys) loaded within this IRP and it is pending.

 

4. Conclusion

As you could see not always the user mode dump will give us the definitive answer for a problem, mainly when most of the threads on user space are waiting for something to happen on kernel space. In this particular case, when reading the kernel dump, we used the !locks command, which displays all locks held on resources by threads. A lock can be shared or exclusive, which means no other threads can gain access to that resource. In this case we saw that we had five threads waiting for exclusive access. The threads that were waiting for exclusive access were part of the wspsrv.exe.

What we can conclude here is that we have a condition where wspsrv.exe was allocating more and more threads without releasing resources (releasing threads) because it was getting stuck waiting for an answer from kernel driver. Some threads were working on I/O, mainly socket and LRPC call (almost socket) that run in Kernel mode. The third party driver is causing every AFD call to take more time and more CPU cycles, the fact that ISA is extremely using sockets amplify the problem. The third party kernel driver was uninstalled from ISA Server and the issue was resolved.

Another takeaway from this particular scenario is that not always that wsprsv.exe is using lot of CPU resources is because it’s an ISA issue. Keep that in mind.

 

Author

Gabriel Koren

Sr. Support Escalation Engineer

Microsoft CSS Forefront Edge Team

 

Technical Reviewer

Franck Heilmann

Sr. Escalation Engineer

Microsoft CSS Forefront Edge Team

 

Categories: ISA, Performance, Troubleshooting Tags:

FCS: 64-Bit Clients do not report the antimalware version in the Computer Details report in the Forefront Client Security management console

January 26th, 2011 Comments off

An issue has been identified in Forefront Client Security (FCS) where when viewing the computer details report from the Forefront Client Security management console, the antimalware client version on 64-bit clients is not reported accurately. This is because of an error in the way the Operations Manger 2005 Management Pack collects this information.

During Forefront Client Security installation, the antimalware package creates several registry keys and creates files in several different directories. During the antimalware installation on 64-bit computers, the following key is created under [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft Forefront\Client Security\1.0\AM]

“InstallLocation=C:\\Program Files (x86)\\Microsoft Forefront\\Client Security\\Client\\Antimalware\\”

The antimalware version is not reported because the MOM agent is 32-bit and on 64-bit computers runs under Windows on windows subsystem. Because of this the MOM agent queries the WOW6432 node of HKEY_LOCAL_MACHINE. When the MOM script queries for the installation path and gets a value of “C:\Program Files (x86)\Microsoft Forefront\Client Security\Client\Antimalware,” it then attempts to discover the file version for MsMpEng.exe, which is not located in this directory. On 64-bit computers MsMpEng.exe is located in “c:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware. When this query fails, the AM version property is set to “N/A”.

If you are experiencing this issue, we suggest you open a support case with using one of the methods documented here: Chris Norman, Senior Escalation Engineer

Categories: 64 bit, computer details, FCS, known issue Tags:

Limited FEP Administrators….

January 25th, 2011 Comments off

One of our support engineers, Jeramy Skidmore, has posted a fantastic article on how to provision a limited FEP Administrator in the Configuration Manager console.

He walks you through the process of provisioning the new FEP Administrator, installing the Configuration Manager console and then the FEP console extensions for Configuration Manager, and then creating the custom MMC for the newly provisioned FEP Admin.

Take a look: http://social.technet.microsoft.com/wiki/contents/articles/setting-up-a-new-fep-administrator.aspx

Thanks Jeramy!!

FEP data collection job fails periodically

January 24th, 2011 Comments off

We wanted to update you about an issue with FEP that you may have seen in your organization. This is a known issue, and we’ll keep you up to date with developments.

Symptoms:

Periodically, the FEP data collection job (FEP_GetNewData_FEPDW_xyz) fails. When the job fails, the FEP Health Management Pack for Operations Manager and the FEP BPA report an error with the FEP datawarehouse job either failing or not running. The failure is in one of the following job steps:

  • Step 6: End raise error section on DW, raise errors that were thrown from DW DB
  • Step 7: ssisFEP_GetErrorsDuringUpload_FEPDW_xyz

Cause:

This happens because of the following scenario:

  1. The antimalware client is from time to time sending a malformed malware detection data item to the FEP server.
  2. The server tries to process this data item as part of the data collection job (FEP_GetNewData_FEPDW_xyz).
  3. During data item processing, the job sees that this data item is malformed and ignores it.
  4. After processing completes, the data collection job (FEP_GetNewData_FEPDW_xyz) looks to see if any data items were malformed, and if so, it fails the job.

Impact:

  • Malformed data items are lost (they don’t get processed); all properly-formed data items are processed.
  • You may experience a small performance impact during the data collection job (FEP_GetNewData_FEPDW_xyz) due to the handling of malformed data items.
  • The data collection job (FEP_GetNewData_FEPDW_xyz) appears as failed in the job history.
  • If the SQL Server Monitoring Management Pack is installed on your Operations Manager server, the data collection job (FEP_GetNewData_FEPDW_xyz) appears with an error.
  • If the Forefront Endpoint Protection Server Health Monitoring Management Pack is installed on your Operations Manager server, the FEP deployment appears as critical and an alert is issued.

Announcing Zero Day, the Novel!

January 23rd, 2011 No comments

You’ve seen the news if you’re my friend on Facebook , follow me on Twitter , or subscribe to the Sysinternals blog : I’m proud to announce that my first novel, a cyberthriller entitled Zero Day , is due to be published by St. Martin’s Press in mid-March…(read more)

Categories: Uncategorized Tags:

New Certificate Required For Antigen 9 Installations on Windows Server 2000

January 20th, 2011 No comments

As of January 18, 2011, Microsoft will be signing antivirus engines used by Antigen with a new certificate in order to continue to ensure secure and reliable virus-engine updates. This will require a new certificate implementation on any Windows 2000 server running Antigen 9.0.

Please see the following Knowledge Base article for clear and detailed instructions on implementing this new certificate: As of 18th January 2011, a new certificate is required to continue updating virus engines for Antigen 9 installed on Windows Server 2000

Rob McCarthy, Sr. Support Engineer

Categories: Antigen Tags:

New Certificate Required For Antigen 9 Installations on Windows Server 2000

January 20th, 2011 No comments

As of January 18, 2011, Microsoft will be signing antivirus engines used by Antigen with a new certificate in order to continue to ensure secure and reliable virus-engine updates. This will require a new certificate implementation on any Windows 2000 server running Antigen 9.0.

Please see the following Knowledge Base article for clear and detailed instructions on implementing this new certificate: As of 18th January 2011, a new certificate is required to continue updating virus engines for Antigen 9 installed on Windows Server 2000

Rob McCarthy, Sr. Support Engineer

Categories: Antigen Tags:

New Certificate Required For Antigen 9 Installations on Windows Server 2000

January 20th, 2011 No comments

As of January 18, 2011, Microsoft will be signing antivirus engines used by Antigen with a new certificate in order to continue to ensure secure and reliable virus-engine updates. This will require a new certificate implementation on any Windows 2000 server running Antigen 9.0.

Please see the following Knowledge Base article for clear and detailed instructions on implementing this new certificate: As of 18th January 2011, a new certificate is required to continue updating virus engines for Antigen 9 installed on Windows Server 2000

Rob McCarthy, Sr. Support Engineer

Categories: Antigen Tags:

New Certificate Required For Antigen 9 Installations on Windows Server 2000

January 20th, 2011 Comments off

As of January 18, 2011, Microsoft will be signing antivirus engines used by Antigen with a new certificate in order to continue to ensure secure and reliable virus-engine updates. This will require a new certificate implementation on any Windows 2000 server running Antigen 9.0.

Please see the following Knowledge Base article for clear and detailed instructions on implementing this new certificate: As of 18th January 2011, a new certificate is required to continue updating virus engines for Antigen 9 installed on Windows Server 2000

Rob McCarthy, Sr. Support Engineer

Categories: Antigen Tags:

Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint is Available

January 20th, 2011 No comments

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 1 for Microsoft Forefront Protection 2010 for SharePoint.

On January 17th Microsoft shipped Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint (FPSP) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the Knowledge Base article: Description of Hotfix Rollup 1 for Forefront Protection for SharePoint

As the installer runs, Server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

 

Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint is Available

January 20th, 2011 No comments

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 1 for Microsoft Forefront Protection 2010 for SharePoint.

On January 17th Microsoft shipped Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint (FPSP) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the Knowledge Base article: Description of Hotfix Rollup 1 for Forefront Protection for SharePoint

As the installer runs, Server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

 

Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint is Available

January 20th, 2011 No comments

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 1 for Microsoft Forefront Protection 2010 for SharePoint.

On January 17th Microsoft shipped Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint (FPSP) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the Knowledge Base article: Description of Hotfix Rollup 1 for Forefront Protection for SharePoint

As the installer runs, Server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

 

Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint is Available

January 20th, 2011 Comments off

On behalf of the security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 1 for Microsoft Forefront Protection 2010 for SharePoint.

On January 17th Microsoft shipped Hotfix Rollup 1 for Forefront Protection 2010 for SharePoint (FPSP) to provide a series of product enhancements and new features. For a complete list of the new features and enhancements included in this rollup, along with directions for download, please see the Knowledge Base article: Description of Hotfix Rollup 1 for Forefront Protection for SharePoint

As the installer runs, Server service restarts may be necessary, so please plan accordingly when applying this hotfix rollup.

Rob McCarthy, Sr. Support Engineer

 

FEP Capacity Planning Worksheet

January 19th, 2011 Comments off

Greetings!

Attached to this blog post is the FEP Datawarehouse Space Capacity Planning worksheet. You can use this worksheet to help estimate the amount of disk space needed based on the following values:

  • Number of client computers in your FEP 2010 deployment
  • The number of days to retain data (the retention period)
  • The average number of Configuration Manager collections to which each client computer belongs
  • The average number of detections per client computer, per day

After you enter in your values in the yellow area, the calculated results appear in the next set of rows. Each row contains information about average record sizes, number of records per computer per day, total size of the record type in the database, and the percent of the total space used by the record item.

The final row in the spreadsheet, in green, gives you the total estimated size of the FEP Datawarehouse, given the values you supplied.

Enjoy!

FCS Path based exclusions do not apply to mount points

January 19th, 2011 Comments off

Hi,

If you’ve configured path based exclusions in FCS 1.0, you may notice that mount points in the path tree are still scanned. This happens because the mount point resides on a different volume than the parent folder. When a file is accessed on the mount point, FCS receives a device path that is not a child of the excluded folder and FCS doesn’t connect the mount point association when it applies the exclusion.

This is a known issue, and we apologize for any inconvenience that this might cause.

Thanks,

Chris Kemper,  Senior Support Escalation Engineer – MSFT

Categories: exclusions, FCS, mount points Tags: