(merging in David Adner's response, b/c I thought it was worthwhile, and
got lost amongst forks)
I don't feel like answering the why right now, sorry ... maybe later if I
remember.
So on the subject of too many paths ...
If you list (at least for AD related [DB] files) all the logical paths,
and thier defaults ... ergo:
<DSA Database File>\ntds.dit
%windir%\ntds\ntds.dit
<DSA Database File-ntds.dit>\ntds.pat
%windir%\ntds\ntds.pat
Note: If you're on Win2k3 (not win2k) you don't need to worry
about the patch file.
<Database Log Files Path>\edb*.log
%windir%\ntds\edb*.log
<Database Log Files Path>\res1.log
%windir%\ntds\res1.log
<Database Log Files Path>\res2.log
%windir%\ntds\res2.log
<Database Log Files Path>\ntds.pat
%windir%\ntds\ntds.pat
Note: Again win2k3, no need to worry about .pat file.
<DSA Working Directory>\temp.edb
%windir%\ntds\temp.edb
<DSA Working Directory>\edb.chk
%windir%\ntds\edb.chk
you'll notice, by default everything is in %windir%\ntds, so _IF_ you
aren't using mail based replication, you could just exclude everything in
that one directory for simplicity. If you've configured your logs and DB
in different directories, you can probably still get away with only two
paths configured.
The FRS DB configuration looks a little more complicated than that, but
similar things could be done there, as I think they ONLY store thier DB
files there.
Cheers,
-BrettSh [msft]
GDO7
This posting is provided "AS IS" with no warranties, and confers
no rights.
--- David Adner ---
Date: Wed, 14 Sep 2005 22:03:29 -0500
From: David Adner <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: RE: [ActiveDir] Sysvol and AV exclusions
The gist of it should be:
Sysvol\Domain\ - Scan
Sysvol\Domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory\ - Don't Scan
Sysvol\Staging\ - Don't Scan
Sysvol\Staging Areas\ - Don't Scan
Sysvol\Sysvol\<domain name> - Don't Scan
So, effectively, you only need to set the 4 folder exclusions. The
reasoning for the Staging* folders and the PreInstall folder is because
the
files created/deleted there are of a transactional nature. The
Sysvol\Sysvol\<domain name>\ folder is a junction point of Sysvol\Domain\,
so there's no point in scanning it. You'll just end up scanning the same
files twice. For the junction point, I don't believe there's anything
inherently wrong with scanning files twice; it's just unnecessary. So if
you're limited to how many folder exclusions you can set I would say
that's
one you could skip, if necessary.
On Thu, 15 Sep 2005, Roger Seielstad wrote:
> Trend Micro's products are fairly robust there too.
>
>
> --------
> Roger Seielstad
> E-mail Geek
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris
> Sent: Wednesday, September 14, 2005 11:40 PM
> To: ActiveDir.org
> Subject: Re: [ActiveDir] Sysvol and AV exclusions
>
> The only product I have seen the full exclusion capabilities in, is Mcafee;
> from ePO this can all be configured centrally. With symantec, paths and file
> types can be excluded centrally, but the actual files have to be configured
> manually on every DC, thus leading to more donkey work and an increased
> scope for error. The only other quirk with symantec is that it does not
> allow for "future" files, that is if its not there, you can't exclude it.
> This was the case up until version 9, 10 I have yet to see. All that being
> said, there is an unsupported hack available from symantec to enable the
> centralised mgmt.
>
> Mark
>
>
> -----Original Message-----
> From: "Tony Murray" <[EMAIL PROTECTED]>
> Date: Thu, 15 Sep 2005 14:09:18
> To:[email protected]
> Subject: RE: [ActiveDir] Sysvol and AV exclusions
>
> Ah, you mean my expectations are too high. :-)
>
> As an illustration of the problem, I have attached a screenshot from CA's
> eTrust AV product. I'm not familiar with the product (nor do I wish to be),
> but from a quick look it does not appear possible to set the exclsions
> according to the 822158 article. Apart from the potential issue of only
> being able to specify a maximum of 16 paths for exclusion, the real problem
> is the inability to include subfolders of folders that have been excluded.
>
> I would imagine that a reasonable percentage of the installed base of AD
> uses CA's product. We're probably talking 10s of thousands of organisations
> worldwide. Our local CA representative was unable to provide a CA
> recommendation for the exclusion list and suggested we refer to Microsoft's
> best practices.
>
> I guess I'm going to have to come up with a "best efforts" compromise
> configuration, combining the recommendations in the 822158 article and the
> capabilities of the CA product.
>
> Tony
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Michael B.
> Smith
> Sent: Thursday, 15 September 2005 10:07 a.m.
> To: [email protected]
> Subject: RE: [ActiveDir] Sysvol and AV exclusions
>
> You obviously haven't dealt with the Exchange Team enough.
>
> :-)
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
> Sent: Wednesday, September 14, 2005 6:01 PM
> To: [email protected]
> Subject: RE: [ActiveDir] Sysvol and AV exclusions
>
> Hi Brett
>
> Thanks for your detailed response. I see you've also managed to sort out
> the formatting of the table in the article. Oh, what power you wield! :-)
>
> The main issue I have is that the article introduces some "new"
> exclusions. I don't think I'm alone in thinking that the general approach
> before this article came out was, "If your AV product is FRS-compliant then
> include SYSVOL in scans.". I am fully aware of the effects of a virus being
> replicated by SYSVOL, having seen it first-hand. SYSVOL does a great job of
> moving a virus around a network very quickly. :-) So it's important to scan
> SYSVOL (or at least parts thereof).
>
> Going back to the issue, the 822158 article sets out exclusions, but doesn't
> indicate why they should be exlcuded. In other words, what is the risk of
> including them? This is relevant for at least one major AV product vendor,
> which has a (somewhat stupid) low limit on the number of files and folders
> that can be excluded on any one server. I'm also not convinced that the AV
> product I'm thinking of can perform the level of granularity of
> inclusion/exclusion suggested in the table.
>
> I can sort of understand why the staging areas would be excluded (compressed
> files, possibility of locking), but why exclude %systemroot%\sysvol and
> %systemroot%\sysvol\sysvol? I can't see anything in my test environment
> that would pose any problems by scanning these folders.
>
> Call me a control freak, but I just don't like seeing a statement such as,
> "Do not scan the following files and folders." with no additional
> explanation.
>
> Tony
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
> Sent: Tuesday, 13 September 2005 10:47 p.m.
> To: [email protected]
> Subject: Re: [ActiveDir] Sysvol and AV exclusions
>
>
> The articles should not be inconsistent.
> The 822158 does mention 814263 (see bullet 2).
>
> 284947 - is how to detect and diagnose excessive FRS replication.
> Noting it might be caused by Anti-Virus software. And mentioning how to
> recover.
> It is not SYSVOL specific, it is FRS specific. But sincej SYSVOL is an FRS
> share, so it applies to SYSVOL, if this should happen to your SYSVOL.
>
> 814263 - is about Anti-Virus programs that are compatible with FRS from a
> generic sense. Againt not SYSVOL specific, FRS specific. You will want one
> of these programs to continue on with your configuration of your DC's
> Anti-Virus program with 822158.
>
> 822158 - Is the penultimate article for DCs and anti-virus software. You
> need to scroll over the very poorly formatted table, near the end.
> You'll note some part of the sysvol folder, are to be scanned and other
> parts are excluded. I believe the parts with the actual files (that people
> can execute during logon due to policy) are to be scanned.
>
> Let me know if you have any issues, or find my statements inaccurate ...
>
> FYI, it is important to get a good anti-virus program (per 814263) and
> configure it correctly (per 822158) to scan your SYSVOL shares, because I've
> know a major company to get a virus in it's SYSVOL, such that everyone who
> logged on would get the virus. This is very nasty. The first thing the
> admin does to check out such an issue is ... log on to a DC, which may not
> have actually been infected with a running copy of the virus. If you can
> get ahold of a virus'd exe, I'd drop it on your SYSVOL just to check it
> works.
>
> Cheers,
> BrettSh [msft]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> On Tue, 13 Sep 2005, Tony Murray wrote:
>
> > Hi all
> >
> > For a while now, I've been including/excluding Sysvol from AV scans
> > based on the recommendations in these articles.
> >
> > Antivirus programs may modify security descriptors and cause excessive
>
> > replication of FRS data in SYSVOL and DFS
> >
> > http://support.microsoft.com/?kbid=284947
> > <http://support.microsoft.com/?kbid=284947>
> >
> > Antivirus, backup, and disk optimization programs that are compatible
> > with the File Replication Service
> >
> >
> > http://support.microsoft.com/kb/815263/
> >
> > In other words, if the AV software is not FRS-compliant then I exlude
> > Sysvol from scans.
> >
> > However, I recently came across the following article:
> >
> > Virus scanning recommendations on a Windows 2000 or on a Windows
> > Server
> > 2003 domain controller
> >
> > http://support.microsoft.com/kb/822158
> > <http://support.microsoft.com/kb/822158>
> >
> > This includes a recommendation to exclude Sysvol, but doesn't really
> > say why. The article doesn't make any reference to the KB284947 and
> > KB815263 articles, so I don't know whether the recommendations are
> > based on that information or new information.
> >
> > Can anyone clarify the situation for me?
> >
> > Tony
> >
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
> ########################################################################
> ####
> This e-mail message has been scanned for Viruses and Content and cleared by
> NetIQ MailMarshal at Gen-i
> ########################################################################
> ####
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
> ########################################################################
> ####
> This e-mail message has been scanned for Viruses and Content and cleared by
> NetIQ MailMarshal at Gen-i
> ########################################################################
> ####
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
