Month: March 2012

by

FAST Query Language (FQL) Operators


FAST Query Language (FQL) operators are keywords that specify Boolean operations or other constraints to operands. The FQL operator syntax is as follows:

[property-spec:]operator(operand [,operand]* [, parameter=”value”]*)

In the syntax:

  • property-spec is an optional property specification followed by the “in” operator.
  • operator is a keyword that specifies an operation to perform.
  • operand is a term expression or another operator.
  • parameter is the name of a value that changes the behavior of the operator.
  • value is the value to use for the parameter name.

Operator names, parameter names, and parameter text values are case-insensitive. White space is allowed within the operator body, but is ignored unless it is enclosed in double quotation marks.

The length of FAST Query Language queries is limited to 2,048 characters.

Overview of FQL Operators

FQL supports the following types of operators:

Type Description Operators
String Enables you to specify query operations on a string of terms. This is the most common operator to use on text terms. STRING
Boolean Enables you to combine terms and sub-expressions in a query. AND, OR, ANY, ANDNOT, NOT, COUNT
Proximity Enables you to specify the proximity of the query terms in a matching sequence of text. NEAR, ONEAR, PHRASE, STARTS-WITH, ENDS-WITH, EQUALS
Numeric Enables you to specify numeric conditions in the query. RANGE, INT, FLOAT, DATETIME,
Relevance Enables you to impact the relevance evaluation of a query. RANK, XRANK, FILTER

For more go to the following link

http://msdn.microsoft.com/en-us/library/ff394462.aspx#fqloperator_or

Advertisements
by

Difference between Audit Logon Events and Audit Account Logon Events


OVERVIEW: Audit Logon Events

The Audit logon events policy records all attempts to log on to the local computer, whether by using a domain account or a local account. On DCs, this policy records attempts to access the DC only. The policy does not, for instance, track a user who uses a domain account to log on at a workstation. (In that case, the user isn’t logging on to the DC; the DC is simply authenticating the user.) To track all domain account authentication, you should use Audit account logon events.

Bottom Line

  • Windows XP, 2000 and 2003: I recommend enabling this policy for success and failure on all computers.
  • Windows Server 2008 and Vista: I don’t recommend managing audit policy at this level because too much noise is generated. Use subcategories instead


OVERVIEW: Audit Account Logon Events

Microsoft should have named the Audit account logon events policy Audit authentication events. On DCs, the policy tracks all attempts to log on with a domain user account, regardless of where the attempt originates. If you enable this policy on a workstation or member server, it will record any attempts to log on by using a local account stored in that computer’s SAM.

Bottom Line

  • Windows XP, 2000 and 2003: I recommend enabling this policy for success and failure on all computers including workstations.
  • Windows Server 2008 and Vista: I don’t recommend managing audit policy at this level because too much noise is generated. Use subcategories instead
by

OVERVIEW: Audit Logon Events


SystemAdmins

The Audit logon events policy records all attempts to log on to the local computer, whether by using a domain account or a local account. On DCs, this policy records attempts to access the DC only. The policy does not, for instance, track a user who uses a domain account to log on at a workstation. (In that case, the user isn’t logging on to the DC; the DC is simply authenticating the user.) To track all domain account authentication, you should use Audit account logon events.

View original post

by

OVERVIEW: Audit Logon Events


The Audit logon events policy records all attempts to log on to the local computer, whether by using a domain account or a local account. On DCs, this policy records attempts to access the DC only. The policy does not, for instance, track a user who uses a domain account to log on at a workstation. (In that case, the user isn’t logging on to the DC; the DC is simply authenticating the user.) To track all domain account authentication, you should use Audit account logon events.

by

Add Ribbon features to sharepoin


Download the feature from
http://spribbonvisibility.codeplex.com/

Project Description
This SharePoint 2010 solution allow site administrator to define who can or cannot see the SharePoint ribbon.

In few words
With this solution you can on each site define if the ribbon is display or not for :

*     Everyone
*     Anonymous user
*     for one or many specific SharePoint groups

Screenshots

*  stsadm -o addsolution -filename PATHConsultPoint.SharePoint.RibbonVisibility.wsp
*  stsadm -o deploysolution -name ConsultPoint.SharePoint.RibbonVisibility.wsp -allowgacdeployment -immediate
*  Activate the feature named ConsultPoint.SharePoint.RibbonVisibility on your site collection

http://spribbonvisibility.codeplex.com/

by

Add features to sharepoin


How to deploy a feature On sharepoin

Installation
*  stsadm -o addsolution -filename PATHthe feature name.wsp
*  stsadm -o deploysolution -name the feature name.wsp -allowgacdeployment -immediate
*  Activate the feature named the fuature name on your site collection