SCCM 2012 DebugView

I found this hidden treasure of information that is not very well known in the System Center community and found it extremely handy.

Open command prompt and type:

The path where SCCM EXE is installed followed by sms:debugview e.g.

"E:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe" sms:debugview

You can create shortcut with this command and save it on your desktop for future use.

This will give you a new option called TOOLS in the SCCM Console. This option is a view into the WMI classes, properties, and attributes. You can run queries in the console and validate the output before creating reports or scripts.

In addition, you will get an option to “Switch to Debug View” for any console. So let us see what this debug view has on offer.

You will see an additional option “Show object details” when you right click on any SCCM object such as computer object, application object, software update groups, etc.

When you click on Show Object Details, it queries WMI to access all relevant properties associated to the corresponding object and displays it in a grid view.

This will also provide extended view in the management console for collection object. I am using these capabilities now for any automation that I am doing in SCCM. I am sure you will find it handy too.

Customize the SCCM Console

Watch this space for more


ETA - July 28, 2012

Basic Understanding Citrix Xen App

Watch this space for more

ETA - 21st July, 2012

Basics of Azure

Wait this section for more

ETA - 14th August, 2012

Understanding TCP/IP Protocol Stack for your job

I don’t want to bog you down with theoretical concepts of TCP/IP stack because I have been studying those diagrams since university days and I never seem to get a hang of it. I will try to make this blog as practical as possible.

Of course, if we talk practical, I need to introduce a tool that will help me visualize TCP/IP. Netmon (or the network monitoring tool) is the tool in question that allows you to monitor the network packets between any 2 end points. It allows you to filter the packets based on any of the below mentioned protocols:

TCP/IP is a set of 5 protocols of which each protocol has a specific role to play. Think of it this ways. When we talk to each other we use a common Language to communicate to ensure the other person understands what we are saying. Similarly, devices on the network communicate with each other based on a common platform called protocols.

A device may talk to another based on one of the 5 TCP/IP protocols. Now let us understand these 5 protocols in the easiest lay man language.

TCP

Think of TCP as making a phone call to your friend. What do you do to talk to your friend over the phone:

1.       You first pick up the phone

2.       Call your friend

3.       Your friend  acknowledges your call

4.       You say HI

5.       He says Hi

6.       You start the conversation over a dedicated connection

7.       You keep checking whether your friend is listening

8.       Since you know the connection is dedicated you will talk with your friend for hours

TCP is very similar to this. I will list down its features and you will see the analogy with the above example.

1.       TCP is Connection Oriented

2.       TCP tracks data that is being sent

3.       TCP is always one end point to another i.e. it is Unicast

4.       TCP keeps checking whether the end point is listening to its messages by using a sequence number

a.       A sequence number tells TCP whether any packet is dropped or not. Think of sequence number as a serial number of packets. The first sequence number is a randomly generated number and each subsequent sequence number will have the sequence number + the size of the packet sent. E.g. if client 1 sends sequence number 22334455 with a 20 byte package. Client 2 will acknowledge, accepting sequence number: 22334455. Then Client 1 will send the next sequence number as 22334475 by adding sequence number with the size of the packet.

5.       Larger packets are sent via TCP since it is important to ascertain the sequence of the packets.

IP

Think of IP as the GPS in your car. Whenever we are lost we look at the GPS to tell us where we need to go. It identifies whether the destination is in the city or is it in the suburbs. IP does something very similar.

Now let us look at some of the IP features and you will be able to drive a correlation.

1.       manages routing tables

2.       determines packet destination

3.       identifies whether a device is remote or local that can be done using routing tables

UDP

UDP is like going to a mall and yelling out your friend’s name. 500 people may hear that you are yelling but only 1 person may recognize you. In another situation, you may yell FIRE FIRE in the mall and everyone will understand your request, acknowledge that there is something wrong, and will run for their lives.

Some interesting facts about this form of communication are:

1.       You are not sure who all are receiving your request

2.       You cannot track who all heard you. Some people may have ignored your yelling

3.       You are talking to multiple people at the same time

4.       You can never ensure that whatever you said has been received properly by everyone.

5.       You will not have 1 hour conversations while yelling. Your talks are generally short

Now compare this with actual features of UDP

1.       Connectionless

2.       No Session

3.       No ability to track data

4.       UDP can be one end point to many

5.       UDP does not contain the sequence no.

6.       Used from Multicast and Broadcast

7.       There is no sequence number for a UDP packet.

8.       E.g. Kerberos request is generally sent via UDP

9.       Smaller packets are sent via UDP since sequence is not critical

ARP

Since we are relating these protocols with real life examples, I will try to map something for ARP as well. Assume that you are in Japan for a business deal and you don’t understand Japanese and your business partner doesn’t understand English. What would you do in this situation?

Simple – hire an interpreter. ARP is that interpreter for you. Therefore some key features of ARP are:

1.       ARP Maps IP address to MAC address

2.       On Ethernet you never talk via IP

3.       IP only helps to route from one device to another

4.       All communication primarily happens using MAC

ICMP

You don’t need any real life examples for understanding ICMP since you use it so often in your daily lives that you are already an expert of ICMP. ICMP is the protocol used sending error messages and for diagnostic purposes.

We all know that the best diagnostic utility that we all use to validate whether the end point device is up and running is PING. Ping and tracert are classic examples of ICMP.

1.       Manages protocol specific communication between TCP/IP enabled devices

2.       e.g. router can send ICMP packet to a device that is having issues in TCP routing

3.       Your DNS server can send ICMP packet requests to your devices confirming its existence

Now let us see how all these protocols come together in a simple network request.

1)      Let’s say you do a dns query for  10.10.10.10 from the source machine. Let’s see what happens:

a.       Your machine does an dns query for 10.10.10.10.

b.      The Network Adapter setting  or the DHCP settings will point the request to the right DNS Server

c.       The DNS Server sends an ICMP request to the source machine confirming whether the DNS server can respond to your request

d.      If the DNS server can respond to the request, it returns a packet providing the A-Record (host name  of the target machine) along with the IP address suggesting that the machine IP address can be resolved and it will also mention whether the IP address is local or remote. This DNS request rides on top of UDP

e.      Two scenarios may arise here:

                                                               i.      The IP Address returned could be local - If IP address is local, source machine then sends an ARP request that broadcasts the IP address to all devices on the local network requesting devices to identify the IP address and provide the corresponding  MAC Address

1.       The interesting aspect is that once the source machine broadcasts the request, all devices in the local network receive the IP address and MAC address of the source machine

2.       Subsequently, all these devices will cache the IP address and MAC address of the source machine so that in future these devices can contact the source machine using the cached details and they don’t have to contact the DNS server going forward

                                                             ii.      The IP address returned could be remote - if IP address is remote, then source machine then sends an ARP request to the gateway of the remote IP address. It will never ARP for the IP address of the target machine if it knows that the IP Address is remote

How clients identify a packet?

·         First 6 bytes in an Ethernet packet denote the destination machine’s MAC address.

·         Let us say there is a broadcast message that is sent over UDP then the first 6 bytes will be – FF FF FF FF FF FF

·         Therefore once a machine receives a packet it will check the first 6 bytes (destination MAC address) and validate whether the packet is for the machine.

·         If the first 6 bytes belong to a machine MAC address then it is a unicast message i.e. point to point communication.

·         If the MAC address does not match then the machine will be checked for FF FF FF FF FF FF to see whether it is a broadcast. If yes, then the machine will assume that packet is meant for its consumption. It will take the packet, process it accordingly, and then forward the packet to the network since it is a broadcast.

·         Generally, if the first two bytes of the first 6 bytes of the Ethernet packet are even, it is a Unicast MAC Address. Also, the first 3 bytes of a unicast MAC address signify the manufacturer name of the network card.

·         A Multicast MAC address is configured for each application. Therefore in case of a multicast, the first 6 bytes will contain the multicast MAC address and if my machine has the registered multicast MAC address, then it will receive the packet else discard it.

·         e.g. Applications that stream audio to a group of people is a multicast.

·         PXE boots are broadcast.

Proposed steps for AD Schema Extension for SCCM 2012

Overview

SCCM 2012 implementation requires AD Schema to be extended in the Active Directory

There is a key requirement to have a backup strategy in place before extending the AD schema since the schema update can only be reversed by a forest recovery.

In order to de-risk the AD schema extension, there needs to be a stung back out approach in case anything goes wrong during the AD schema upgrade. Most organizations require a change request to be in place before extending the AD schema and most change requests require a back out strategy. This section will serve the purpose of having a strong back out strategy. The detailed approach is as follows:

Approach

1. Logon to the Domain Controller holding the Schema Master FSMO role using Schema Admins credential
   
2. Perform Backup
   
   1. Back up system state and the system disk on a domain controller using ntdsutil.exe
      
   2. Dump the current schema into a file for comparison.  From a command prompt, run the command:  Ldifde -f Before_Schema_Update.ldf –"cn=schema,cn=configuration,dc=domain,dc=root"
      
3. Isolate the server
   
   1. Disable Outbound Replication on the server
      
   2. At a command prompt, run the command: "repadmin /options +DISABLE_OUTBOUND_REPL" without the quotation marks.
      
   3. Unplug the physical network connection to ensure no communication could occur with other domain controllers.
      
4. Extend the Schema
   
   1. There are 2 options to extend the AD Schema:
      
      1. Using LDIF File:
         
         1. Modify the LDIF file by replacing DC=x with DC=domain1,DC=domain2,DC=com
            
         2. At a command prompt, run the command "ldifde –i –f ConfigMgr_ad_schema.ldf –v –j <location to store log file>"
            
      2. Using extadsch.exe (preferred)
         
         1. Execute extadsch.exe
            
5. Validate the Schema Extension
   
   1. Using LDIF File: - Check for the log file mentioned in the command prompt command
      
   2. Using extadsch.exe – Check for extadsch.log in the root directory
      
   3. Open ADSIEdit and perform a visual check of the schema to validate whether all classes are added into AD
      
   4. Dump the current schema into a file and compare with the one obtained in step 2b. From a command prompt, run the command: Ldifde -f After_Schema_Update.ldf -d "cn=schema,cn=configuration,dc=domain,dc=root"
      
   5. Compare the content in the file Before_Schema_Update.ldf and After_Schema_Update.ldf to ensure proper extension is completed.
      
6. If the Schema Extension is Successful
   
   1. Re-enable Outbound Replication on the server
      
   2. At a command prompt, run the command: "repadmin /options -DISABLE_OUTBOUND_REPL" without the quotation marks.
      
   3. Re-connect the network cable
      
   4. Force replication of Active Directory
      
   5. Allow time for replication to be completed before Installing SCCM
      
7. Backup Strategy (Only to be implemented if the Schema Extension encounters a Catastrophe / Failure)
   
   1. Option 1 - Restore a domain controller through restore from backup
      
      1. Restore AD from backup media (non-authoritative restore).
         
      2. Verify Active Directory restore.
         
   2. Option 2 - Recover a domain controller through reinstallation.
      
      1. Demote the Domain Controller
         
      2. Re-promote the Domain Controller and let in-bound replication fix the Domain Controller
         

Disclaimer

The above mentioned steps must be tested in QA, Pre-prod, or Development environments before trying in Production.

 

  

SCCM 2012 – Customize / Extend Hardware Inventory

Overview

 SCCM 2012 has come a long way in terms of inventory management. It has come a long way since SMS days when the MOF file had to be deployed on each client to collect the inventory. In SCCM 2007, there was a sms_DEF.mof that was required to define the WMI classes that are to be inventoried.
In SCCM 2012, the concept of hardware inventory is fairly simple. You can define any WMI classes that are to be inventoried in SCCM Console as part of Client Agent settings. These client agent settings can be advertised on collections. This means that now you have the flexibility to customize the inventory gathering based on models, operating systems, business units etc
The client then reads all inventory information through WMI (Windows Management Instrumentation). The SCCM Client agent then imports these classes when it runs the machine policy refresh cycle. Therefore, the client now polls for any changes to the configuration chages from the server.

Detailed Step by Step procedure for extending Hardware Inventory in SCCM 2012
There are 8 key steps to extend inventory in SCCM:

1. Create the MOF file to extend inventory
2. Make a backup of the Inboxes\CliFiles.src\HInv\Configuration.MOF file on the CAS
3. Copy the contents of the MOF file between the two customer headings at the very bottom of the Configuration.MOF
4. Manually compile this modified Configuration.MOF file on a test client using MOFComp
5. Bring up properties of the Default Client Agent Settings on your CAS
   1. Select Hardware Inventory and click Set Classes
   2. Click Add and connect to \\WKS\root\CIMV2 (where WKS is the name of the client used above)
   3. Select <the class added> and press OK
6. Monitor PolicyPv.log on the primary to which the client reports indicate that it has updated policy to reflect the new class
7. pdate Machine Policy on the client side, allow a minute or two for that to process and then force a Hardware Inventory cycle
8. Once the data is relayed to the MP and procesed there, it should appear in Resource Explorer.

In the section below I will discuss each of these steps in detail.

Let me take a small example: We want to inventory "HKEY_LOCAL_MACHINE\SOFTWARE\Absolute Software Inc\" registry key with Esn (where Esn is a Reg_Sz or String value)

STEP 1 - Create the MOF file to extend inventory
This is where most of us run into issues. We must ensure that the correct MOF file is created. Here is a sample code for the registry that we want to inventory.

// Registry property provider #pragma namespace ("\\\\.\\root\\cimv2") #pragma deleteclass("Absolute_Software_Inc", NOFAIL) [DYNPROPS] Class Absolute_Software_Inc { [key] string KeyName; String Esn; }; [DYNPROPS] Instance of Absolute_Software_Inc { KeyName="Absolute Software Inc"; [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Absolute Software Inc|Esn"),Dynamic,Provider("RegPropProv")] Esn; }; TAKE CARE OF WORD WRAP

It is important to understand how to create this MOF file, therefore let us look at it section by section.


#pragma namespace ("\\\\.\\root\\cimv2")
You must declare the namespace into which you will be adding the new class. You use the #pragma command to inform the MOF compiler that you will be using the specified namespace to add this object to. In this example, you enumerate the root \cimv2 namespace of the local computer. This is where the information for the new provider will be located.
Note the extra backslash characters in the definition of the namespace. The first backslash character specifies a special character that follows. The second backslash character defines the special character that you want to use. This is known as "escaping" special characters so that the MOF compiler will interpret them literally.


#pragma deleteclass("Absolute_Software_Inc", NOFAIL)
The #pragma deleteclass command is used in SMS/Configuration Manager hardware inventory modification to delete class information from WMI repositories. It is recommended to use deleteclass if you are testing new hardware inventory modifications and making changes to your mof edits during testing and want to start with a clean slate each time the client compiles the new mof file. When deleting WMI classes from clients that have already performed hardware inventories (especially if you have changed a Key field), you should also delete the class information stored in the site database as well.


[DYNPROPS]
The DynProps qualifier identifies a class as having properties that are maintained by the property provider identified by the Provider qualifier


Class Absolute_Software_Inc
{
[key] string KeyName;
String Esn;
};
Here we add the class definition in the root\cimv2\sms namespace to specify inventory collection. A new Class – Absolute_Software_Inc is defined. It also defines the KeyName variable with string datatype.


[DYNPROPS]
Instance of Absolute_Software_Inc
{
KeyName="Absolute Software Inc";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Absolute Software Inc|Esn"),Dynamic,Provider("RegPropProv")] Esn;
};


Next we instantiate the class, and define the properties of the class that need to be inventoried. The actual registry value that is retrieved is called the Property context. This value must have the same name as the registry value that you are enumerating. The name must be enclosed in quotation marks. The display name is the name by which the data will be referenced. MOF file syntax is derived from Microsoft® Visual C++ syntax for class definitions.


Step 2 – Take a backup of the Inboxes\CliFiles.src\HInv\Configuration.MOF file on the CAS
This is extremely important. The Configuration.MOF file must be backed up before before making any changes.


STEp 3 - Copy the contents of the MOF file between the two custom headings at the very bottom of the Configuration.MOF
Open the configuration.mof file and browse to the end of the file and look for the following content:


#pragma namespace ("\\\\.\\root\\cimv2")


//========================
// Added extensions start
//========================


//========================
// Added extensions end
//========================


Copy paste the content of the MOF File created earlier between the Added extensions start.


Step 4- Manually compile this modified Configuration.MOF file on a test client using MOFComp.exe
Open command prompt and type the following command to compile the configuration.mof file on a TEST CLIENT.


mofcomp.exe -check Configuration.mof
This will check the syntax of the MOF File.

 mofcomp.exe Configuration.mof

 Step 5- Add hardware inventory in SCCM from the remote computer namespace
Open the SCCM Console On the Central Administration Site server and Click on Administration -> Client Settings -> Hardware Inventory -> Set Classes

Click on Add.

Click on Connect -> Select the name of the TEST CLIENT and enter the WMI Namespace as root\cimv2 and click on CONNECT

This should enumerate all the Classes including the one we just created – Absolute_Software_Inc

Select the Class that needs to be added and click on OK and it should show up in SCCM as well.

Step 6 - Monitor PolicyPv.log on the primary to which the client reports indicate that it has updated policy to reflect the new class
Update "Machine Policy Retrieval & Evaluation Cycle" on the client side. Allow a minute or two for that to process and then force a "Hardware Inventory" cycle.


Validate the InventoryAgent.log on the Test Client to see whether our class has been inventoried.

Similarly, policypv.log will report any updates to the inventory class.

Once the data is relayed to the MP and procesed there, it should appear in Resource Explorer.

0.0 Understanding System Center End Point Protection

Application Description: Microsoft SCCM 2012 integrates with System Center End Point Protection (SCEP) to provide end to end capability to manage anti-virus client installation, policy updates, and definition updates.
The key aspects of SCEP integration with SCCM include:

1. Setup End Point Protection Server
2. Configure and Install SCEP Client Agent
3. Configure and Install SCEP Antimalware Policies
4. Configure and Install Antivirus Definition
5. Validate SCEP Settings on Client
6. Configure Alerts in SCEP

This guide is created with the following intention:

1. Give an understanding of HOW SCEP WORKS at tandem with SCCM 2012
2. What considerations do SECURITY TEAMS need to validate while configuring SCEP
3. What considerations do SCCM EXPERTS need to validate while configuring SCEP
4. Give an understanding of HOW TO CONFIGURE SCEP end to end with SCCM 2012

6.0 Configure Alerts for EndPoint Protection

To be performed by SCCM Administrators and security team

 
Alerts inform the administrator when specific events have occurred, such as a malware infection. Alerts can be displayed in the Configuration Manager console, through reports, or optionally can be emailed to specified users.

 
In order to configure Email Alerts in SCCM perform the following steps:

• Open the SCCM Console and click on Administration -> Site -> CAS Server -> Settings -> Email Notification

• Enter the SMTP Server Details and the Sender Address.

• Once the SMTP connection is tested, browse to the collection that needs to be monitored for any malware issues, right click on the collection, click on Properties, and Click on Alerts.

• Select all the alerts that need to be set and notified for the collection.
• Once the alerts are created, Go to Monitoring-> Alerts and select the alert for which email subscriptions are to be created.

• Click on Create Subscription and enter the Name and Email Address of all users who should receive the emails whenever the alert is triggered.

Other guides:

1. Setup End Point Protection Server
3. Configure and Install SCEP Antimalware Policies
4. Configure and Install Antivirus Definition
5. Validate SCEP Settings on Client
6. Configure Alerts in SCEP
Configure and Install SCEP Client Agent

 

5.0 Validate SCEP Settings on Client

To be performed by SCCM Administrators and security team

 
Once the SCEP Client is installed on a client, it will show up under Start -> All Programs.

You can also view the latest defintion status and policy details by clicking on Help -> About System Center End Point Protection

The deployed Antivirus Definitions Version can also be located in the registry settings under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Signature Updates\ASSignatureVersion

Details of the Antimalware Client Agent can be accessed at the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0C243024-B7AF-478B-B6F1-574A4AB0E07C}

Other guides:

1. Setup End Point Protection Server
3. Configure and Install SCEP Antimalware Policies
4. Configure and Install Antivirus Definition
5. Validate SCEP Settings on Client
6. Configure Alerts in SCEP
Configure and Install SCEP Client Agent

4.0 Configure and Install Antivirus Definition

To be performed by SCCM Administrators and security team

 
SCCM ASUP Server will be configured to download the antivirus definitions on a daily basis. The Antivirus definitions are downloaded by the ASUP component of the SCCM Server.
In order to configure the ASUP server to download antivirus defintions, log on to the central adminiration site server

• open the SCCM Console -> Go to Administration -> Sites -> Central Administration Site Server ->Settings -> Configure Site Components -> Software update Point
• Click on Classifications and select Definition Updates
• Click on Products and select Forefront EndPOint Protection
• Click on Sync Schedule and set the synchronization schedule as desired

Once configured, SCCM will sync the patches with Microsoft website and all antivirus definitions will show up under Software Library -> All Software updates

 

Manage Antivirus Definitions

To be performed by SCCM Administrators and security team
Once the definitions show up in SCCM, the next logical steps include:

1. Create a grouping of relevant updates. These are referred as Software Update Groups
2. Download the definitions in SCCM
3. Deploy the definitions on a target collection

Operationally this entire process will be automated by utilizing the Automatic Deployment Rules feature of SCCM. Ensure the following entities are available before creating an Autotic Deployment Rule:

1. A common share to deploy the defintions
2. Target collection to deploy the definitions

Follow the following steps to create Automatic Deployment Rules for SCEP:

1. On the SCCM Console, go to Software Library -> Automatic Deployment Rule-> Right Click and Click on Create Automatic Deployment Rule
   
2. Name the Deployment Rule and link it to an appropriate collection. Ther are two options to select either to add the definitions to existing software update group or to create a new one. Select to create a new software update group so that a new update gets created periodically and the security team can monitor which definition gets deployed when. There is an additional overhead to delete earlier software update groups which can be automated.
   

1. Click Next and Select appropriate deployment settings
2. Click Next and select the Filter for deploying the Antivirus Defintions.
   

   
3. Click Next, and set the Evaluation Schedule. Ensure that the evaluation is scheduled to run after the patches are synced up by the Activue Software update Point e.g. in our case the update sync happens at 10:00am and the evaluation happens at 2:00pm everyday.
   
   
   
   
   
4. Click Next and set the deployment schedule for the definitions. The defintions will be available as soon as possible while the installation deadline will be set to expire 2 hours after the deployment.
   

   
   
   
5. Click Next and set the User Experience and Alerts as required
6. Click Next and set the Download Settings. For the first time that we create the automated rule, a new deployment package can be created a linked to the share where all the definitions should be downloaded.
   
   
   

   
   
   
7. Click Next and specify the Distribution Points where the defintions should be distributed. In a production environment, a defintion should go to all the DPs in the environment.
   
   
     
8. Once the rule is set, the definitions will start getting downloaded at the location specified

 
 
Other guides:

1. Setup End Point Protection Server
3. Configure and Install SCEP Antimalware Policies
4. Configure and Install Antivirus Definition
5. Validate SCEP Settings on Client
6. Configure Alerts in SCEP
Configure and Install SCEP Client Agent

3.0 Configure and Install SCEP Antimalware Policies

To be performed by SCCM Administrators and security team


SCEP Client policies define where the client can obtain the defintion updates, when does it perform scans, and what files are scanned.
In order to create a new policy, right click on Assets and Compliance and click on Create Antimalware Policy. As a best practice, a new policy should be created and deployed to a limited number of computers using a collection.

 The SCCM Antimalware Policy allows us to set the following options:

• Scheduled Scans
• Scan Settings
• Default Actions
• Real-Time Protection
• Exclusion Settings
• Advanced Settings
• Threat Overrides
• Microsoft Active Protection Service
• Definition updates

The section below provides the best practice settings for the Antimalware Policy settings. The details of each scan setting are available at the following link:
http://www.microsoft.com/sqlserver/en/us/get-sql-server/try-it.aspx



Scheduled Scans
The schedules scans settings enable to specify the behavior of the scan details for a client.

Setting Description	Setting	Default
Scan time	4:00pm	2:00am
Check for the latest definitions updates before running a scan	True	False
Randomize the scheduled scan start time (within 30 minutes)	True	False

Scan Settings

The scans settings specify the content that should be scanned on a client.

Setting Description	Setting	Default
Scan email and email attachments	True	False
Scan archived files	True	False
Randomize the scheduled scan start time (within 30 minutes)	True	False

Default Actions
The default actions allow SCEP to respond to certain threats in a specified manner.

Real-Time Protection
The real-time protection settings allow SCEP to ascertain whether to scan real time files such as program activity, scripts, and system files etc.

Exclusion Settings
The exclusion settings allows SCEP to exclude certain files and file types from Antivirus scans

The following files are excluded from any antivirus scans.

Advanced Settings

Advances settings allow SCEP to configure additional settings such as user interaction with the agent and other antivirus settings.

Threat Overrides

Threat Override settings allow SCEP to define remediation actions that can be taken for a specified threat name when detected during a scheduled scan.

All the threats are enlisted in SCEP and an appropriate action can be ascertained.

Microsoft Active Protection Service
The Microsoft Active Protection Service enables MS to collect and send information about and detected Malware.

Definition updates


The defintion updates setting allows SCEP to determine the methodology to deploy definitions.

Setting Description	Setting	Default
Check for EndPoint	6 hours	8 hours
Check for end point protection definitions daily at	12 PM	3 PM
Set sources and Order for Endpoint Protection definition updates	3 Updates from SCCM Updates from UNC Share Updates from Malware Protection Center	1

Antivirus definitions will also be downloaded manually to a UNC path on the Primary Site Server such that the definitions are available to all clients even if the SCCM CAS server goes down and is not able to dync the latest definitions from Microsoft.

Other guides:

1. Setup End Point Protection Server
3. Configure and Install SCEP Antimalware Policies
4. Configure and Install Antivirus Definition
5. Validate SCEP Settings on Client
6. Configure Alerts in SCEP
Configure and Install SCEP Client Agent