Creating Incident Ticket from 3rd party application which send HTML content in the Body of the Email sometimes get really difficult to process and since the ServiceDesk Incident Management Description field doesn't support HTML, Email Monitoring Project convert the Body of the email from HTML to plain text which remove all the HTML tags and make the information difficult to understand as the formatting of the email is completely removed. To solve this issue I design a small modification which converts this sort of specific Email's Body in PDF attachment to the Ticket keeping almost the exact same formatting. The Trick is to use HTML to PDF converter Component

As you can see in the below mentioned Email Monitoring Workflow Project we have a used a additional components to accommodate this functionality. 

Kindly note this is just an demonstration of the capabilities of Symantec Workflow, These Modifications are not officially supported by Symantec Support. In this demonstration we modified the Email Monitoring project only for POP but the same can be done for IMAP very easily. The attached Email Monitoring Project has the logic for both.

(In this Example we are modifying the Email Monitoring Workflow to Create tickets from the Critical Notification Sent from SEPM Server as the SEPM Server send's the list of computers with there respective status in a tabular form, it become difficult to understand it when formatting is remove so we can use this modification to create a PDF report from that notification and attach it to the ticket for further action.)  

.

In order to accomplished this we need below mentioned components and arrange them in the order as show below.

1) Initialize Data Component.

2) Text Contains Rule Component

3) 2 AddNew Data Element Components and a Copy Data Element to New Location Component

4) Convert HTML to PDF Component.

5) Merge Text Component

6) Get Document Category by Name Component and Add Document Component

7) True False Rule Component.

Arrange Initialize Data Component, Text Contains Rule Component, 2 AddNew Data Element Components, Convert HTML to PDF Component and a Copy Data Element to New Location Component as show below.

In Initialize Data Component, Select DataType as Logical and Set the value to False and Variable name to SEPMEMail. 

In the Text Contain Rule Component we need to define the verification condition based on which we will be deciding whether this is an email sent by SEPM Server or Normal user. We can use two logics here one, based on Sender's Email Address which I have used below or we can use the Subject as a deciding factor, To use Subject for classify emails change the Variable from SingleEmailMessage.From to SingleEmailMessage.Subject and Type the desired subject in Contains by click Eclipse(...).

The Next Component is the First Add New Data Element Component, Select the DataType as Logical and check the Value check box, this will set the value of the SEPMEmail variable to true. 

The Second New Data Element will store the Incident number in the later part of the flow, so right now we just have to initialize it and set the value is none/null. Select the DataType as text and variable name as process id.

This is the component which is doing all the heavy lifting as it converting the HTML body of the Email to Pdf.

Since we have created a pdf file from the original body of the email we need to put something simple to replace body which will be used in ticket as description and notify the technician that the details are attached as PDF to the ticket.

Copy the New Body to SingleEmailMessage.Body

Now we have to set rest of the three components Get Document Category by Name Component, Add Document Component and True False Rule Component as shown below.

Additional Changes in the ProcessMessage Linked Model 

Last Part of the puzzle.

Final Results :)

So I've been seeing some issues in our environment where the Symantec Management agents are installed but broken in some way, either WMI is broken or there are problems with the agent itself. Symptoms can vary from agent not showing any tasks ever ran, lots of tasks still in running state, patches not running, no policies assigned, no task server assigned, agent crashes in event log, etc... I found that using a combination of number of tasks still running, when the agent last checked for tasks, when agent last policy request was and which task server it was assigned to (broken agents usually show no task server assigned) gives me a good indication if the agent/WMI is broken.

I knew I wouldn't be able to rely on the CMDB to find agents that are really busted so I set out writing a PowerShell script to collect some basic data about the agents for me. What I have is a script that will take a list of computers, check if they're online and then try to collect some data about the agent via the WMI classes that it exposes. If the WMI query fails for some reason I write that out so I can go back and follow up and reinstall those agents or run the WMI fix. So far this has worked pretty well at identifying computers that are having issues. Further down the road I may include automating sending the agent reinstall job via aexschedule since we still have DS 6.9 around.

I tried to add enough comments to the script to make it easy to follow but here’s an outline of what’s being done.

First we need to setup a few things, our list of computers, 1 per line as a normal text file. Next we specify our output files, $OutFile is where everything is going to get output to as a CSV for easy import into excel and then $BrokenOutFile is going to be just the pc's that failed the WMI queries. Since we still have DS 6.9 I may at some point automate sending the agent reinstall job using aexschedule using this list but for now I want to know how/why the agent is broken.

After setting the paths for the input and output files I set a date threshold for how far back to go to check for running tasks. I have mine set to go back one week (-7 days) but you can go back as far as you want. Next we build some empty arrays to hold the data and then an old function I found that does an alternate way to query WMI. Sometimes WMI can be so broken that queries will hang indefinitely, this function fixes that with a timeout.

Now we can get into the meat of the script. First start looping through list of computers and try to ping them to make sure they’re online. If they are I start doing my WMI queries in a try-catch block so that if any of the queries fails it’ll jump down to the catch block and write out that WMI failed. The first query gets the task history and collects the ones were Status =0 and ReturnCode=-1 which corresponds to the tasks which are still in the running state and then use the count property to get the number of tasks still running. You’ll see in the script we need to convert from the WMI time format to something that’s more human readable, accomplished via some .NET wizardry.

Once all the data is gathered from WMI it’s added to a custom object that I created to hold the data while the script is running. The catch block and the else statement for if ping failed use the same technique. Once the list of computers is done, the files are written out to disc as CSV’s. At the bottom I left in some code that commented out that could be used to send the completed file in an email since sometimes the script can take a while to run against large groups of computers and it can be nice to just let it run over night or over a weekend.

Further down the road I might turn this into a server side script that will populate the data into the CMDB using a custom data class.

Let me know if there's any questions or improvements/feature enhancements.

In this article, I am going to write down the steps that I took to create a WinPE 3.1 boot image that can be used to contact the GSS console.  This is by no means required, and, in all honesty, doesn't work correctly 100% of the time.  I will give examples later.

Here is a great resource that talks about the WAIK, using it to create an image, and has the links for getting it: Adventures with WinPE 3.1

Thanks EdT!  He also touches on the idea of scripting out a lot of the process, which I do as well.

The first thing you need to do is get the Microsoft WAIK, and install it.  You can use a VM for this, or your regular machine, it's up to you.

When we go to build the PE, we will be using the 32bit PE since the ability to ping the console is built into a 32bit app.

Second, on the server that is running your Ghost Solution Suite console, open the Ghost Boot Wizard.  Select WinPE, click edit.  Highlight the WinPE 2.0 boot partition you are using that has all of your drivers.  Make sure you highlight this one, and not a stock one.  Click copy, and give it a nice short name (like WinPE3).  Make note of where it is storing the files (ProgramData\Symantec\Ghost\Template\COMMON).  Your newly made PE will be in that folder under its own folder with the name you gave it.  Remember this.

Third, make yourself a new WinPE 3.0 PE on your PE'ing machine!  Open the "Deployment Tools Command Prompt" as an admin from the machine you installed the WAIK.  DON'T CLOSE THIS PROMPT.  NOT UNTIL THE VERY END.  Think of a nice folder name for your PE so you remember where it is!  (this guide will use "C:\winpe" as the location)  Next, come up with a holding directory for files and folders before you copy them over (maybe c:\bootcd\makepe).  Now, create your PE with the following commands

1. copype x86 c:\winpe
2. copy c:\winpe\winpe.wim c:\winpe\ISO\sources\boot.wim

Awesome, you now have the PE made, and it is time to mount that WIM file with the following command

1. dism /mount-wim /wimfile:c:\winpe\winpe.wim /index:1 /mountdir:c:\winpe\mount

Now, this allows you to mess with the WIM file as a directory instead of a file.  It is located at c:\winpe\mount.  This is the section of the fun where we add all of the utilities, files, custom backgrounds, drivers, etc.  I will give some examples, as well as the commands for adding drivers, since that is important

I HIGHLY recommend you do the following at this point (some of these really are required for this to work as a Ghost PE, but not all of it)

1. Add IMAGEX or GIMAGEX to your holding folder (its a nice graphical front end for IMAGEX) and also copy it to the "c:\winpe\mount\windows\system32" directory.  Necessary?  No, but its a useful tool for the future.
2. Make a folder called "Scripts" under your holding folder earlier.  We will come back to this later!
3. Open a console boot partition that you have made some time before inside Ghost Explorer and steal all of the stuff in the Ghost directory.  Put that all in a directory in your holding folder called "Ghost".  You want the following things in this folder: copy.bat (from the console partition), GDISK32, GhConfig32, Ghost32, Ghostoem32, ghreboot.bat (from the console partition), GhRegEdit32, ghvp.bat (from the console partition), NGCTW32 (this is the biggest piece, you NEED this.  Get it from the console partition if necessary), your pubkey.crt, and the file VPartition.dll (from the console partition).  Copy that directory over to "c:\winpe\mount\Ghost".  This whole step is MANDATORY for this to contact the server.  I am sure there will be questions on this step.  Ask below.
4. Make a file named STARTNET.CMD in your holding folder.  This is super important.  I will come back to it as its own numbered list in a minute.
5. Want a custom background?  Name it "winpe.bmp", put it in your holding folder, and also put it in the "c:\winpe\mount\windows\system32" folder
6. Go get the program "GETMAC" from an old XP install.  You know you have one.  Put it in the holding folder and the mount\windows\system32 folder just as above.  This is not required, but it is really nice to be able to pull the MAC address without all the other ipconfig stuff.

You will see me using this holding folder a lot.  It is nice because if you mess up, you have duplicates and can just move them over!  Also allows for great scripting!

Now, back to that command prompt.  run the following commands:

1. dism /image:%_location%\mount /add-package /packagepath:"C:\program files\windows aik\tools\petools\x86\winpe_FPs\WinPE-HTA.cab"
2. dism /image:%_location%\mount /add-package /packagepath:"C:\program files\windows aik\tools\petools\x86\winpe_FPs\WinPE-Scripting.cab"
3. dism /image:%_location%\mount /add-package /packagepath:"C:\program files\windows aik\tools\petools\x86\winpe_FPs\WinPE-WMI.cab"

Doing those adds abilities to your PE to run HTML stuff, scripts, and return WMI info.  There are more, but those 3 are really good.

Now, I recommend you go get Network drivers for your network cards (Win7 has a lot of them, but you will probably still need some.), maybe even a chipset driver too.  Put all the folders inside a folder somewhere.  For the network drivers, you only need the NDIS62 drivers, and all drivers you are going to include MUST BE 32bit Win7 drivers!  for sake of argument, lets say you stored them in a folder called "c:\bootcd\makepe\winpedrivers32".  Now from the command prompt you have open, run the following command

1. dism /image:c:\winpe\mount /add-driver /driver:c:\bootcd\makepe\winpedrivers32 /recurse

That will put all of your drivers in your PE image.  It does take a minute.

Now, we are going to go back to some of the folders and files from earlier, and make some new ones too!!  Note the PE isnt "committed" yet.

Now we start in on the scripts.  This is important.  They help so much.  Make each of these as its own CMD file in that "Scripts" folder you made in the holding area.

First, make a script called "setPath.cmd".  It has one line in it.  This sets up your PATH variable so you can just call your scripts

1. set path=%path%;x:\Program Files;x:\ghost;x:\scripts;

Second, make a script called "reboot.cmd".  It has one line in it.  This allows you to type "reboot" at the prompt and the computer will restart

1. wpeutil reboot

Third, the most important script.  This is flat out taken from a boot partition and makes the comp phone home to the console.  call it "startGhost.cmd".  It has the following (yes line 3 is blank)

1. rem --- This will remove any traces of virtual partition from hard drive ---
2. x:\ghost\gdisk32.exe /revert  >> x:\ghost\startlog.txt
3.  
4. rem --- This will create primary OS drive configuration ---
5. x:\ghost\ghost32.exe /setosdrives /blind >> x:\ghost\startlog.txt
6. start x:\ghost\ngctw32.exe -console

NGCTW32.exe -console is what opens the window that sends and acknowledges your GSS server.  Super important

Add some more scripts if you want.  i have ones that reinitialize the WINPE networking, start backup sessions, even use VNC inside the PE!  (i can talk about that later if people want)

Now, copy the SCRIPTS folder over into the c:\winpe\mount directory.

Next, we turn our attention to the STARTNET.CMD file we made.  Edit it, and add in the following

1. wpeinit
2. wpeutil disablefirewall
3. start /min cmd.exe
4. cmd /c x:\scripts\startGhost.cmd
5. x:\scripts\setpath.cmd

This file is what gets everything going.  First we initialize the PE, then we shut off the firewall to help kill some issues.  We open ANOTHER cmd prompt for later use (it will be minimized by default).  We then start up the ghost phone home.  We then set our PATH as before so we can call other scripts if we want to (from this window, the other one wont have the path set, but system32 is in the path by default, so GETMAC works from that window, so does IPCONFIG, etc)

Copy the STARTNET.CMD file from your holding directory to c:\winpe\mount\system32.  Yes you want to replace it with your new, more awesome one.

Now its time to commit.  Settle down, start a WinPE3.0 session.  Run the following:

1. dism /unmount-wim /mountdir:c:\winpe\mount /commit

That seals in your changes.  Next, we replace the WIM with the new one you just lovingly hand made.  run this:

1. copy c:\winpe\winpe.wim c:\winpe\ISO\sources\boot.wim /y

Make an ISO of it!  You need to know where you are saving it.  How about c:\ISOs?  Run this:

1. oscdimg -n -bc:\winpe\etfsboot.com c:\winpe\ISO c:\ISOs\winpe3.iso

See how there is no space after the "-b", it just slams right into the "c:\" part.  That is on purpose.  There is no space there.  Don't do it.

PEing is hard work!  Now toss it in your CD burner oven and let it bake you a lovely CD.  Don't have time?  Need to use the USB microwave?  Sure!  mount that ISO in the utility of your choice.  Take a thumb drive (when I build the above, it fits on a 512MB drive [where can you even find them that small anymore?!])

Go into DISKPART, and select the USB drive. Run the following commands after that select command you just did to pick the USB drive and not your HD.  Super important you pick the right one, since were going to nuke it (microwave joke!)

1. clean
2. create partition primary
3. select partition 1
4. active
5. format fs=NTFS quick

Now, to give an example, we will assume your ISO drive is E:\, and your thumb drive is L:\.  Change this to make it match yours.  You don't want to overwrite the wrong drive, or copy the wrong files

1. xcopy E:\*.* /s/e/f L:\

That copies the ISO onto the thumbdrive.

If done correctly, you can now actually boot a comp from the CD or thumb drive.  When it starts pinging your GSS server "sending...acknowledged" you can pull it out and it will keep doing it!

Remember earlier when I said remember where GSS kept that WinPE3 folder under COMMON?  Open your folder, open "Sources" and replace the boot.wim in there with the one from the CD/USB key.  Confirm the move!  Now, you can NEVER EVER AGAIN open that PE in the Ghost Boot Wizard.  It will give you lots of errors.  But it does work.

If you go into the GSS console, you can now assign this as the Virtual Partition under the client tab.

The reason I had you take the working partition you normally use as the starting point and copying it is that the MANIFEST files are still used by GSS, and it still checks the manifest for drivers it assumes will be there.

So, since nothing is perfect, I'm sure you want to know what I know is broken (since I mentioned it earlier).  I have a weird situation where, from Windows, i can issue a Clone command, or a Config command, but not both together.  The config will fail after the clone succeeds.  But I can do the clone, let it succeed, then do the config.  Extra weird is that if I boot to that CD/USB key and issue the clone and config together, it works!  But only if the machine was already in the PE.

Please leave questions or feedback.  This is still a work in progress, it is a nice way to make a new boot CD.  It's also faster than taking a CD and ghosting the partition onto it.

After this topic came up 2 times already at the same customer I need to write it down somewhere to remind myself and why not share it with the community.

Problem Description

The silverlight console starts showing errors instead of loading the jobs and tasks details for a selected computer. Other Computer might still show the list of jobs and task run and running as usual.

Silverlight gives an error message about some unknown exception during loading the Taskhistory.

If you use the Resource Manager and check Jobs and Tasks Summary there you will still see all the Tasks run.

Cause

The silverlight module doesn't really like NULL values. In this case it was older deleted Tasks. When silverlight tries to get details for the Task Instance it will be presented with NULL for some of the Taskinstances of the computer. If you check in the database you will also find those Instance orphans.

Solution

Run the following SQL query to find all the taskinstances that don't have any taskversion or task/job item attached anymore. After a backup of the DB you could change the "select * " to "delete " and get rid of the orphaned taskinstances. If I missed something please feel free to comment.

select * from taskinstances where taskinstances.TaskInstanceGuid in(select ti.TaskInstanceGuid from taskinstances ti

left join itemversions iv

on ti.TaskVersionguid = iv.Versionguid

left join item i

on iv.Itemguid = i.guid

join Taskinstanceresults tir

on tir.TaskInstanceGuid = ti.TaskInstanceGuid

where i.Name is NULL and i.Guid is NULL and iv.ItemGuid is NULL)

There is a new feature on DLP 12.0: Content Root Enumeration. 

The Content Root Enumeration is a function about Auto-discovery of servers and shares.

Content Root Enumeration enables you to locate servers and shares within a domain and filter them by IP range or server name. Share discovery works only for CIFS-compliant file servers, including those with DFS file shares.

Content Root Enumeration scans produce a list of servers and shares that you can use directly in file system targets for Discover scanning, or export to a CSV file. A Content Root Enumeration scan does not scan the content of the servers and shares it discovers, but it enables you to find servers and shares in your domain and configure automated scanning of them.

Here are the steps to configure the Content Root Enumeration on DLP 12.0:

1. From Enforce Console, choose 'System' --> 'Settings' --> 'Directory Connections', click 'Create New Connection':

2. Fill in the nessary information to create the directory connection:

3. Select 'Manage' --> 'Discover Scanning' --> 'Content Root Enumeration':

4. From the drop-down list of 'Directory Connection', select the directory connection which added on step2:

5. Fill in the IP range that need to discover:

6. After the save the configuration, click 'Start':

7. After the scan, the file servers and share folder will be discovered:

8. Click the link to check the result:

Note:

You need to set up the DNS server on the DLP Enforce Server in order to resolve the FQDN of the file server.

And, you need a Domain User credential at least to finish the auto-discovery.

Hi all

I'm pleased to announce the availability of a new Enterprise Vault whitepaper that covers the challenges around archiving a single Exchange server with multiple EV servers.

Enjoy!

Dan

In the past I posted some blog about ebooks available for free and that can help my IT admin day-to-day activities.

Here you can find some of these blogs and also in addiction a large list of IT manuals, ebooks and other helpful documents for Sysadmins. I hope that both the novice and the expert will find useful information in this collection.

Patch Management Solution is a great product that comes with a large number of reports, however it is missing what I would consider a key feature: trending. The ability to keep track of compliance over time.

Now from a Product Management stand-point I can understand why it would be very difficult to put in place (too many options - diverging needs etc). But from an "outsider" it's very easy to put in place.

Today we will look at the first enabler to such feature: a patch trending report.

Patch trending report sources:

-- #########################################################################################################
-- PART I: Make sure underlying infrastructure exists and is ready to use
if (exists(select 1 from sys.objects where name = 'PM_TRENDS_TEMP' and type = 'U'))
begin
	truncate table PM_TRENDS_TEMP
end
else
begin
CREATE TABLE [dbo].[PM_TRENDS_TEMP](
	[_SWUGuid] [uniqueidentifier] NOT NULL,
	[Bulletin] [varchar](250) NOT NULL,
	[Update] [varchar](250) NOT NULL,
	[Severity] [varchar](250) NOT NULL,
	[Custom Severity] [nvarchar](100) NULL,
	[Release Date] [datetime] NOT NULL,
	[Compliance] [numeric](6, 2) NULL,
	[Applicable (Count)] [int] NULL,
	[Installed (Count)] [int] NULL,
	[Not Installed (Count)] [int] NULL,
	[_SWBGuid] [uniqueidentifier] NOT NULL,
	[_ScopeCollection] [uniqueidentifier] NULL,
	[_Collection] [uniqueidentifier] NULL,
	[_StartDate] [datetime] NULL,
	[_EndDate] [datetime] NULL,
	[_DistributionStatus] [nvarchar](16) NULL,
	[_OperatingSystem] [nvarchar](128) NULL,
	[_VendorGuid] [uniqueidentifier] NULL,
	[_CategoryGuid] [uniqueidentifier] NULL
) ON [PRIMARY]
end

if (not exists(select 1 from sys.objects where type = 'U' and name = 'TREND_WindowsCompliance_ByUpdate'))
begin
	CREATE TABLE [dbo].[TREND_WindowsCompliance_ByUpdate](
		[_Exec_id] [int] NOT NULL,
		[_Exec_time] [datetime] NOT NULL,
		[Bulletin] [varchar](250) NOT NULL,
		[UPDATE] [varchar](250) NOT NULL,
		[Severity] [varchar](250) NOT NULL,
		[Installed] [int] NULL,
		[Applicable] [int] NULL,
		[DistributionStatus] [nvarchar](16) NULL
	) ON [PRIMARY]

	CREATE UNIQUE CLUSTERED INDEX [IX_TREND_WindowsCompliance_ByUpdate] ON [dbo].[TREND_WindowsCompliance_ByUpdate] 
	(
		[Bulletin] ASC,
		[Update] ASC,
		[_exec_id] ASC
	)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

end

-- PART II: Get data into the trending table if no data was captured in the last 24 hours
if (select MAX(_exec_time) from TREND_WindowsCompliance_ByUpdate) <  dateadd(hour, -23, getdate()) or (select COUNT(*) from TREND_WindowsCompliance_ByUpdate) = 0
begin

-- Get the compliance by update to a "temp" table
insert into PM_TRENDS_TEMP
  exec spPMWindows_ComplianceByUpdate
			@OperatingSystem = '%',
			@DistributionStatus = 'Active',
			@FilterCollection = '01024956-1000-4cdb-b452-7db0cff541b6',
			@StartDate = '1900-06-29T00:00:00',
			@EndDate = '2020-06-29T00:00:00',
			@pCulture = 'en-GB',
			@ScopeCollectionGuid = '91c68fcb-1822-e793-b59c-2684e99a64cd',
			@TrusteeScope = '{2e1f478a-4986-4223-9d1e-b5920a63ab41}',
			@VendorGuid = '00000000-0000-0000-0000-000000000000',
			@CategoryGuid = '00000000-0000-0000-0000-000000000000',
			@DisplayMode = 'all' 

declare @id as int
	set @id = (select MAX(_exec_id) from TREND_WindowsCompliance_ByUpdate)
		insert into TREND_WindowsCompliance_ByUpdate
		select (ISNULL(@id + 1, 1)), GETDATE() as '_Exec_time', Bulletin, [UPDATE], Severity, [Installed (Count)] as 'Installed', [Applicable (Count)] as 'Applicable', _DistributionStatus as 'DistributionStatus'
		  from PM_TRENDS_TEMP
end

-- Return the latest results
select *, applicable - installed as 'Vulnerable',  cast(cast(installed as float) / cast(applicable as float) * 100 as money) as 'Compliance %'
  from TREND_WindowsCompliance_ByUpdate
 where _exec_id = (select MAX(_exec_id) from TREND_WindowsCompliance_ByUpdate)
--   and cast(cast(installed as float) / cast(applicable as float) * 100 as money) < %ComplianceThreshold%
--   and applicable > %ApplicableThreshold%

union

select max(_exec_id), max(_exec_time), Bulletin, '-- ALL --' as [update], '' as severity, sum(installed) as 'Installed', sum(applicable) as 'Applicable', '' as DistributionStatus,  sum(applicable) - sum(installed) as 'Vulnerable',  cast(cast(sum(installed) as float) / cast(sum(applicable) as float) * 100 as money) as 'Compliance %'
  from TREND_WindowsCompliance_ByUpdate
 where _exec_id = (select MAX(_exec_id) from TREND_WindowsCompliance_ByUpdate)
 group by Bulletin
--having sum(applicable) >%ApplicableThreshold%
--   and cast(cast(sum(installed) as float) / cast(sum(applicable) as float) * 100 as money) < %ComplianceThreshold%
 order by Bulletin,[update]

A Quick look at the report proceedings:

The report takes care of a temp table used to store the compliance results, of the Patch trending table (to create it on the first execution with all the required indexes to keep it fast under load) and of course of inserting the results from the temp table to the trending table (only if the last insert was done more than 23 hours prior).

Finally we return the latest result set, whether it was just inserted or already cached.

I will not detail the above SQL but I need to explain the decisions taken in the compliance report execution, shown here:

  exec spPMWindows_ComplianceByUpdate
			@OperatingSystem = '%',
			@DistributionStatus = 'Active',
			@FilterCollection = '01024956-1000-4cdb-b452-7db0cff541b6',
			@StartDate = '1900-06-29T00:00:00',
			@EndDate = '2020-06-29T00:00:00',
			@pCulture = 'en-GB',
			@ScopeCollectionGuid = '91c68fcb-1822-e793-b59c-2684e99a64cd',
			@TrusteeScope = '{2e1f478a-4986-4223-9d1e-b5920a63ab41}',
			@VendorGuid = '00000000-0000-0000-0000-000000000000',
			@CategoryGuid = '00000000-0000-0000-0000-000000000000',
			@DisplayMode = 'all' 

As you can see we are not writing our own compliance report, but rather we leverage the built-in procedure that return the compliance by update. The parameters are hard set to ensure we do not have any limits (collection = all computer, trustee scope = symantec admin) but we limit the result set to only show Active updates.

One important note on what "Active" means in this case. An active update is an update that is enabled and ready for distribution. So you can have a mix of updates with enabled policy, disabled policies or not policies returned in this report.

I have some report that picks up data from the trending table and filters out updates that do not have an enabled policy - but this will be another article subject.

A quick Howto implement

Implementing this feature, as promised in the article title is simple: create a report and set it to the SQL type. Paste the full code above and save the report. Once it has run you should be able to see the current compliance status for your environment.

Next you need to create an Automation Policy that will run the report daily.

Voila.

Next in the series

We will look at some reports to get some graphical views of the patch trending, as well as report on the meta-data and global compliance. There'll also be some report for the compliance by enabled update, as mentioned above.

And as a final teaser, I will boldly state here that I am considering creating a small web-application to provide a nice graphical view of the patch compliance trending using the gorgeous Google graphic API's (very much like what we have in aila-web).

Hi all

I'm pleased to announce the availability of a new Visio poster detailing Enterprise Vault 10 Exchange Journaling with Clearwell integration.

In the Zip file you will find both JPG and Visio formats.

Regards

Dan

Please find knowledgebase articles available for SymantecLiveupdate Administrator (LUA) - current version available is 2.3.2.99. Articles are split in several catagories to allow you fast browsing and search for interesting topics. Both Symantec official KB resources and Symantec Connects resources included. Please look for a smiley - with it I have marked articles with specific relevance. As attachments you can find the .pdf documents of the Symantec LiveUpdate™ Administrator User's Guide.  I will be updating this "knowledgebase" as soon as any new articles regarding LUA are being published or any new version of this software is released.

About LiveUpdate Administrator (from Symantec LiveUpdate™ Administrator User's Guide)
LiveUpdate Administrator is an enterprise Web application that allows you to manage updates on multiple internal Central Update servers, called Distribution Centers. Using LiveUpdate Administrator, you download updates to the Manage Updates folder, and then send the updates to production distribution servers for Update clients to download, or to testing distribution centers, so that the updates can be tested before they are distributed to production. You can download and distribute updates on schedule, allowing you to create a low maintenance, reliable system that can be set up once, and then run automatically. Updates can also be manually downloaded and distributed as needed.

Updates are downloaded from an external site to an internal LiveUpdate Administrator server. From there, the updates can either be sent immediately to a production distribution center to be downloaded by Update clients, or sent to a testing center, so that the updates can be tested. Once the updates have passed your testing requirements, they are sent to the production center, on a schedule you determine.

Important notes about the product:

• LUA 2.3.0 and previous releases utilize versions of PostgreSQL which have reached end of life.  All customers using previous versions of LUA are advised to migrate to LUA 2.3.1 as soon as possible.
• Known Vulnerability in Symantec LiveUpdate Administrator Windows version 2.3.1 and prior -> Insecure File Permissions  Local Elevation of Privilege - Medium (http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=2012&suid=20120615_00) - Recommendation: Update to Symantec LiveUpdate Administrator Windows version 2.3.2
• LUA 2.3.2 includes a new feature for Enabling Automatic Symantec Product Catalog Updates - please check TECH201472 for reference
• In order allow LUA to provide your SEP 12.1 RU2/RU3 clients/SEPM with definitions please update your Product Catalog and select the definitions for SEP 12.1 RU2 (those definitions are being used as well by the RU3 product)
• When contacting Symantec Support for assistance regarding LUA please always collect following data:
  - Collect Luadebuginfo.zip using Troubleshoot link in the upper-right corner of the LUA interface (http://www.symantec.com/docs/TECH92654)
  - Export the LiveUpdate Administrator 2.x Server Event Log in .csv format (http://www.symantec.com/docs/HOWTO61146)
  - For LUA 2.3 and above always export the LUA server's Configuration Recovery File (http://www.symantec.com/docs/TECH159239)

SYMANTEC KB ARTICLES

VERSIONS / REQUIREMENTS:

How to obtain the latest version of Symantec LiveUpdate Administrator (LUA) 2.x
http://www.symantec.com/docs/TECH134809

What's new in LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH171578

System Requirements for LiveUpdate Administrator 2.1 (LUA 2.1)
http://www.symantec.com/docs/TECH105358

System Requirements for LiveUpdate Administrator 2.2 (LUA 2.2)
http://www.symantec.com/docs/TECH92719

System Requirements for LiveUpdate Administrator 2.3 (LUA 2.3)
http://www.symantec.com/docs/TECH173272

System Requirements for LiveUpdate Administrator 2.3.1 and 2.3.2
http://www.symantec.com/docs/TECH177544

LiveUpdate Administrator 2.3.x: Release Notes
http://www.symantec.com/docs/TECH155523

BEST PRACTICES:

Best Practices for LiveUpdate Administrator (LUA) 2.x
http://www.symantec.com/docs/TECH93409

When to use LiveUpdate Administrator?
http://www.symantec.com/docs/TECH154896

LiveUpdate Administrator 2.x and Symantec Endpoint Protection Manager on the same computer
http://www.symantec.com/docs/TECH105076

Is it Supported to Configure Unmanaged Symantec Endpoint Protection Clients to Update from LiveUpdate Administrator 2.x rather than the Symantec Endpoint Protection Manager?
http://www.symantec.com/docs/TECH123388

About Updating the Symantec Product Catalog in LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH201472

About Installing LiveUpdate Administrator 2.x on a Windows XP, Windows Vista or Windows 7 Operating System
http://www.symantec.com/docs/TECH152817

INSTALLATION / CONFIGURATION:

Installing and Configuring LiveUpdate Administrator (LUA)
http://www.symantec.com/docs/TECH102701

LiveUpdate Administrator 2.x installation walk through
http://www.symantec.com/docs/TECH102862

How to backup and restore LiveUpdate Administrator (LUA) configuration in LUA 2.3
http://www.symantec.com/docs/TECH159239

How much hard disk space is consumed by LiveUpdate Administrator 2.x for content updates?
http://www.symantec.com/docs/TECH90823

How To Determine the Corresponding Product for a LiveUpdate Administrator 2.x File
http://www.symantec.com/docs/TECH131177

LiveUpdate Administrator 2.x: What product selections are needed for specific versions of Symantec Endpoint Protection?
http://www.symantec.com/docs/TECH139618

Type of files and extensions associated with definitions in LiveUpdate Administrator 2.x with Symantec Endpoint Protection 12.1
http://www.symantec.com/docs/TECH166279

Configuring LiveUpdate Administrator (LUA) to download updates from another LUA Server
http://www.symantec.com/docs/TECH105741

Updating downloads in an internal LiveUpdate Administrator 2.x Server using the downloads from an external LiveUpdate Server
http://www.symantec.com/docs/TECH106254

How to distribute definition content from a LiveUpdate Administrator 2.x (LUA 2.x) server to an isolated network.
http://www.symantec.com/docs/HOWTO44060

How to configure a LiveUpdate Administrator 2.x Distribution Center to use the UNC protocol
http://www.symantec.com/docs/TECH106222

TROUBLESHOOTING:

How to Collect Troubleshooting Information from LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH92654

How to Export the LiveUpdate Administrator 2.x Server Event Log
http://www.symantec.com/docs/HOWTO61146

Exporting Client Settings for Windows and Java LiveUpdate Clients from the LiveUpdate Administrator 2.x
http://www.symantec.com/docs/TECH97460

PERFORMANCE / TUNING:

LiveUpdate Administrator 2.2 Performance Tuning
http://www.symantec.com/docs/TECH96391

Tuning LiveUpdate Administrator 2.x's PostgreSQL Database
http://www.symantec.com/docs/TECH93476

UPDATING OTHER PRODUCTS VIA LUA:

Configuring Symantec Mail Security for Domino to Update from an internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH202619

About updating Brightmail Antispam definitions from LiveUpdate Administrator 2.x or other local repository server
http://www.symantec.com/docs/TECH174535

Distributing virus definitions for Symantec Mail Security for Microsoft Exchange (SMSMSE) via LiveUpdate Administrator 2.x.
http://www.symantec.com/docs/TECH96018

How to use LiveUpdate Administrator 2.x with Symantec Security Information Manager 4.5, 4.6, 4.7 and SSIM Event Collectors
http://www.symantec.com/docs/TECH91326

Updating Symantec Mobile Security 7.2 Devices from an Internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH192276

Updating Windows Mobile Devices from an Internal LiveUpdate Administrator 2.x Server
http://www.symantec.com/docs/TECH159934

SYMANTEC CONNECT

RECOMMENDED:

LiveUpdate Administrator 2.3 Vulnerability - Please Upgrade!
https://www-secure.symantec.com/connect/forums/liv...

Managing LiveUpdate Administrator 2.x Space Usage.
https://www-secure.symantec.com/connect/articles/m...

LiveUpdate Administrator 2.x Server Connection Recommendations
https://www-secure.symantec.com/connect/articles/l...

A Helpful LiveUpdate Administrator 2.x Analogy
https://www-secure.symantec.com/connect/articles/h...

LiveUpdate Administrator: Product Selection Guide
https://www-secure.symantec.com/connect/articles/l...

How Big are Current Symantec Endpoint Protection Definitions?
https://www-secure.symantec.com/connect/articles/h...

INSTALLATION / CONFIGURATION:

LiveUpdate Administrator: How to configure a remote Distribution Center
https://www-secure.symantec.com/connect/articles/l...

Installation and configuration of LUA
https://www-secure.symantec.com/connect/articles/i...

Configuring Distribution Center in LUA
https://www-secure.symantec.com/connect/articles/c...

Group Update Provider v/s Liveupdate Administrator
https://www-secure.symantec.com/connect/articles/g...

Using IIS Logs to Check LiveUpdate Administrator 2.x Health
https://www-secure.symantec.com/connect/articles/u...

Illustrated Guide to Configuring LiveUpdate Administrator 2.x for SMSMSE 6.5.5
https://www-secure.symantec.com/connect/articles/i...

SYMANTEC CONNECT VIDEOS

LiveUpdate Administrator: How to configure a remote Distribution Center
https://www-secure.symantec.com/connect/videos/liv...

Install LUA (Live Update Administrator) and Configure for Symantec Endpoint Protection
https://www-secure.symantec.com/connect/videos/ins...

LiveUpdate Administrator 2.3: What's New
https://www-secure.symantec.com/connect/videos/lua...

Symantec Data Loss Prevention comes with over 40 pre-configured reports to help customers manage their business. These reports allow customers to meet compliance requirements, assess business risk, provide oversight and manage remediation operations, and see trends across business units of the organization.

Symantec Data Loss Prevention offers the following pre-built reports, divided into Network, Endpoint Prevent, and Discover reports.

• Network reports provide summaries for the Data Loss Prevention for Network products.
• Endpoint Prevent reports provide summaries for Symantec Data Loss Prevention Endpoint Prevent.
• Discover reports provide summaries for the Data Loss Prevention for Storage products as well as for Symantec Data Loss Prevention Endpoint Discover.

Here is the list and description about all the pre-configured reports:

Content:

• Overview
• Installation & Configuration
• Troubleshooting

Overview

In an ESX environment, you can install a native Symantec Critical System Protection agent and apply policies to monitor and protect the local host. However, ESXi does not allow agent installation or local enforcement. Instead, a Symantec Critical System Protection observer system is used to monitor the ESXi host remotely by using VMware-supported APIs and command line tools such as vCLI. This observer system is referred to as the Symantec Critical System Protection Collector host and is similar to the VMware Management Assistant (VMA). VMA is a virtual machine that manages agents that interact with ESXi hosts. VMA is not used because it no longer supports the capture of forwarded ESXi Syslog events and the choice of deployment scenarios is limited.

Symantec recommends that the Symantec Critical System Protection Collector system should be a single-purpose system that is dedicated to monitor a set of ESXi servers. The Symantec Critical System Protection Collector system contains account and password information for the monitored ESXi servers, copies of ESXi server configuration files and logs, and VM guest configuration files. Therefore, you should limit login access to the Symantec Critical System Protection Collector system in the same way you limit login access to the ESXi servers or vCenter Servers. The ESXi credential store and other ESXi files are protected by operating system ACLs – only the root user has access to them. Symantec recommends you to use Symantec Critical System Protection Prevention and Detection policies for additional protection of the Collector host system, as you would with any other important server in the organization.

Symantec Critical System Protection Collector systems can be either SLES 10 (32-bit and 64-bit), SLES 11 (32-bit and 64-bit), or Red Hat 5.5 (32-bit and 64-bit). The Symantec Critical System Protection Collector system does not require many system resources, so configuring it as a virtual machine makes the most sense from a manageability standpoint.

The Symantec Critical System Protection Collector system includes the following components:

■ Base Linux Platform (SLES, RHEL)

■ VMware vCLI

■ Symantec Critical System Protection agent

■ Remote File Synchronization (RFS)

Installation & Configuration

Note: All the below steps require to be logged in as root user.

ESXi Host Configuration

ESXi Host Configuration from vSphere:

• ESXi Shell set to Start and stop with host:
  • Configuration tab > Software > Security Profile > Services > Properties > ESXi Shell > Options…
• ESXi clock synchronized:
  • Configuration tab > Software > Time Configuration > Properties
• Enable syslog forwarding (outgoing UDP port 514):
  • Configuration tab > Software > Security Profile > Firewall > Properties

ESXi Host Configuration:

• ESXi Host set with static IP:
  • Login locally > Configure Management Network > IP Configuration

Installation of the Collector Node Linux Based Platform

Preparing the Linux Based Platform

Setup a virtual machine for RHEL 5.5 or SLES 10/11.

• Disable the firewall
• Disable SELinux (RHEL)/AppArmore (SLES)
• Install VMware tool

Note: CentOS 5.5 is an alternative to RHEL. The configuration is the same as for RHEL.

Installing vCLI on Linux Systems with Internet Access

Before you can install the vCLI package on a Linux system with Internet access, that system must meet following prerequisites.

■ Internet access. You must have Internet access when you run the installer because the installer uses CPAN to install prerequisite Perl modules.

■ Development Tools and Libraries. You must install the Development Tools and Libraries for the Linux platform that you are working with before you install vCLI and prerequisite Perl modules.

■ Proxy settings. If your system is using a proxy for Internet access, you must set the http:// and ftp:// proxies, as follows:

export http_proxy=<proxy_server>:port

export ftp_proxy=<proxy_server>:port

Installing Required Prerequisite Software for Linux Systems with Internet Access

If required prerequisite software is not installed, the installer stops and requests that you install it. Installation of prerequisite software depends on the platform that you are using.

Installing Required Prerequisite Software

yum install openssl-devel libxml2-devel e2fsprogs-devel

 SLES 10, 64 bit. yast -i openssl-devel libxml2-devel-32bit e2fsprogs-devel-32bit

 SLES 10, 32 bit. yast -i openssl-devel libxml2-devel e2fsprogs-devel

SLES 11 64 bit. yast -i openssl-devel libuuid-devel libuuid-devel-32bit

SLES 11 32 bit. yast -i openssl-devel libuuid-devel

Installing the vCLI Package on a Linux System with Internet Access

Download vCLI 5.1 from VMware website.

Install the vCLI package and run a command to verify installation was successful.

To install vCLI

1. Untar the vCLI binary that you downloaded.

tar –zxvf VMware-vSphere-CLI-5.X.X-XXXXX.i386.tar.gz

A vmware-vsphere-vcli-distrib directory is created.

2. If your server uses a proxy to access the Internet, and if your http:// and ftp:// proxy were not set when you installed prerequisite software, set them now.

export http_proxy=<proxy_server>:port

export ftp_proxy=<proxy_server>:port

If your server does not use a proxy to access the Internet, set the http:// and ftp:// proxy as follows:

export http_proxy=

export ftp_proxy=

3. Run the installer from the vmware-vsphere-vcli-distrib directory itself.

./vmware-install.pl

4. To accept the license terms, type yes and press Enter.

The installer connects to CPAN and installs prerequisite software. Establishing a connection might take a long time.

5. On RHEL, when prompted to install precompiled Perl modules, type no and press Enter to use CPAN.

The installer connects to CPAN and installs prerequisite software. Establishing a connection might take a long time.

6. Specify an installation directory, or press Enter to accept the default, which is /usr/bin.

A complete installation process has the following result:

■ A success message appears.

■ The installer lists different version numbers for required modules (if any).

■ The prompt returns to the shell prompt.

If you accepted the defaults during installation, you can find the installed software in the following locations:

■ vCLI scripts – /usr/bin

■ vSphere SDK for Perl utility applications – /usr/lib/vmware-vcli/apps

■ vSphere SDK for Perl sample scripts – /usr/share/doc/vmware-vcli/samples

See the vSphere SDK for Perl documentation for a reference to all utility applications. After you install vCLI, you can test the installation by running a vCLI command or vSphere SDK for Perl utility application from the command prompt.

Installing the Critical System Protection Agent

1. Export the agent binary file and the agent-cert.ssl file (agent certificate) on the Collector Node Server,
   • For RHEL 5.5, 32-bit: agent-linux-rhel5.bin
   • For RHEL 5.5, 64-bit: agent64-linux-rhel5.bin
   • For SLES 10, 32-bit: agent-linux-sles10.bin
   • For SLES 10, 64-bit: agent64-linux-sles10.bin
   • For SLES 11, 32-bit: agent-linux-sles11.bin
   • For SLES 11, 64-bit: agent64-linux-sles11.bin
2. Change the permissions for the binary file.

chmod a+x <agent_binary_file>

3. Run the binary file to start the agent installation.

./agent64-linux-rhel5.bin

4. Follow the prompts until the installation completes.

Note: Make sure to enter the agent name during installation (see Troubleshooting for details).

5. Restart the computer if prevention was enabled.

That completes the installation of the agent.

Installing the Remote File Synchronization (RFS) Support Utility Tool

About the Symantec Critical System Protection ESXi Support Utility

Remote File Synchronization (RFS) is a support utility tool that is installed on the Collector host to help the Symantec Critical System Protection agent monitor multiple ESXi hosts. RFS periodically synchronizes ESXi host configuration files, Virtual Machine Configuration files (VMX files), and selected ESXi log files. The local agent computer with policies applied performs the file integrity and log monitoring activities.

The files that are available for monitoring are specifically exposed by the VMware APIs. Not all the files that are visible when you log into the ESXi host are available for monitoring purposes.

RFS performs the following functions:

■ Remote access to a designated ESXi host by using a VMware-encrypted credential store.

■ Discovery and transfer of changed ESXi host configuration files.

■ Discovery and transfer of changed ESXi host log files of interest to Symantec Critical System Protection ESXi detection policy.

■ Discovery and detection of VMs that are registered or de-registered from the ESXi host.

■ Discovery and transfer of changed Virtual Machine VMX configuration files for VMs that are registered with the ESXi host.

RFS is periodically executed based on a scheduled interval that is configured by the administrator. For example, the interval might be 10 minutes, 30 minutes, 2 hours and so on. After an initial one-time file population, only the files that are changed on the ESXi host are copied to the local Collector host.

Note: During the initial one-time file population, you may see a lot of File Create events in the console.

The ESXi Syslog log file is handled separately from RFS. Syslog configuration settings at the ESXi host are used to forward its Syslog to the Symantec Critical System Protection Collector node for monitoring purposes.

The Symantec Critical System Protection agent performs file integrity monitoring based on the mirrored files. Monitoring includes checking for changes in last modification date, size, name, and file content. The policy, as configured by the Symantec Critical System Protection console users, determines the event severity, rule name, and other parameters associated with FIM and log monitoring events.

Each ESXi host can be viewed as a virtual agent on the 5.2.9 console. All the events generated for a particular ESXi host will be available to be viewed for that virtual agent.

Installing and Setting up the ESXi Support Utility

The following Perl modules are prerequisites for the Symantec Critical System Protection ESXi support utility. You must ensure that these modules are present before you use the support utility:

■ Date::Parse

■ File::Copy

■ File::Path

■ File::Basename

■ Sys::Hostname

■ Text::CSV

■ Text::CSV_XS (optional)

To download a Perl module

Install cpanm to make installing other modules easier.

◆ Open a terminal window and run the following command:

cpan App::cpanminus

◆ Then run the following command for each module to install:

cpanm <Module>::<Name>

For example, cpanm Date::Parse

To install and set up ESXi utility

1. The ESXi Support utility is installed as a part of Symantec Critical System Protection 5.2.9 agent installation on a Linux operating system. The default directory for the ESXi support utility is:

/opt/Symantec/scspagent/IDS/bin/esxi_fim

2. When you install ESXi support utility for the first time, open a terminal window, and run the following command located in the default directory:

rfs_config.sh -setup

3. Specify a directory where you want to store the ESXi host files that are retrieved by the tool, or press Enter to accept the default, which is /fim/scspfim.

4. When prompted for the synchronization interval, type a valid interval between 3 to 60 minutes. It adds a cron job to the root user's crontab to run the RFS utility based on the specified synchronization interval.

Note: If you want to create a synchronization interval of more than 60 minutes, type 60 when you run the setup, and then manually edit the cron-tab entry /etc/crontab file to change the synchronization interval.

You can also run the setup silently by providing the above information in the following way:

rfs_config.sh -setup -fimpath <path for the root directory> -syncinterval <interval in minutes>

5. The ESXi support utility can now be configured to add, modify, delete, and list ESXi Hosts.

rfs_config.sh -addHost -server=<addr> -username=<user> -password=<passwd>

After you provide all the values, the setup script configures the following settings on the local system:

■ Updates the conf/esxi_fim_host.conf file by setting the ESXi_HOSTS entry to ESXi host name/IP address.

■ Creates a credential store under conf/esxi_fim_hostcred by using a vCLI command. It also populates the store with an entry for the ESXi host and the user account credentials.

■ Creates the CollectorNode_<hostname> directory under /fim/scspfim/ for the Collector Node.

■ Creates a directory named with the IP address of the monitored ESXi host under /fim/scspfim/.

■ If the Syslog mode is on:

■ Adds an entry in the etc/syslog-ng/syslog-ng.conf file to accept the forwarded syslogs from the ESXi host.

■ Configures the remote ESXi host to forward its events to the local collector by using a vCLI command.

When you install the ESXi support utility for the first time, you should apply the vSphere ESXi Detection Policy to start monitoring the ESXi Hosts. You can only apply the vSphere ESXi Detection Policy after you have run the setup.

6. Once the policy applied, run the first synchronization.

./rfs_config.sh –runrfs

About RFS OPTIONS parameters (rfs_config.sh)

-help

-version

-setup

■ -fimpath=<fimrootdir>

■ -syncinterval=<mins>

rfs_config.sh –setup -fimpath=<fimrootdir> -syncinterval=<mins>

-addHost

rfs_config.sh -addHost <Mandatory Options> [Optional Options]

■ -server=<IP address or host name>

■ -username=<user>

■ -password=<passwd>

■ -protocol=<protocol>

■ -port=<port>

■ -syslogon

■ -syslogoff

-modifyHost

rfs_config.sh -modifyHost <Mandatory Options> [Optional Options]

■ -server=<addr>

■ -username=<user>

■ -password=<passwd>

■ -protocol=<protocol>

■ -port=<port>

-deleteHost

rfs_config.sh -deleteHost <Mandatory Options>

■ -server=<addr>|all

■ -username=<user>

-listHost

-upgrade

-runrfs

Troubleshooting

Troubleshooting and verifying steps for RFS

RFS Setup

• If during the RFS Setup it fails to create the /fim/scspfim directory, create it manually and update the conf/esxi_fim_root with an entry that identifies the directory for the FIM root.
• If during the installation of the CSP Agent you do not enter its name, the Collector Node folder will be created as SCSPCollectorNode_ and will be reporting to the Management Server as such.

The only way to fix this is by reinstalling the CSP agent and enter its name during the installation process.

RFS Synchronization fails

• Review the rfs.log located in the /fim/scspfim/CollectorNode_<hostname> directory for errors.
• Check that the directory with the ESXi IP address is created under /fim/scspfim/.
• Enable Trace mode to get more details:
  • Edit esxi_fim_host.conf by changing the last 0 to 1 on the ESXHOST= line.

Uninstall RFS Utility

Uninstalling the RFS Utility requires to uninstall the Critical System Protection Agent.

1. Make sure no Prevention policy other than NULL is applied to the Agent,
2. Run rpm –e SYMCcsp,
3. Reboot the server to complete the uninstallation.

Troubleshooting and verifying steps for VMware vCLI & ESXi

Uninstall VMware vCLI

1. Go to to the directory where you installed vCLI (default is /usr/bin).
2. Run the vmware-uninstall-vSphere-CLI.pl script.

The command uninstalls vCLI and the vSphere SDK for Perl.

ESXi syslog settings

• Check that syslog forwarding is configured from vSphere > Configuration tab > Software > Advanced Settings > Syslog. You should see the following in the Syslog.global.logHost setting:

udp://<collectornode_IP_address>:514

References

VMware vCLI Download link

https://my.vmware.com/group/vmware/details?downloadGroup=VSP510-VCLI-510&productId=285

Vmware vCLI Documentation

http://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vcli.getstart.doc/cli_install.4.5.html

SCSP Agent Installation

https://www-secure.symantec.com/connect/articles/how-install-scsp-agent-windows-unix-and-solaris

SCSP vSphere Support Guide

https://www-secure.symantec.com/connect/articles/symantec-critical-system-protection-52-ru9-docs

CPAN

http://www.cpan.org/modules/

YUM (RHEL)

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/c1-yum.html

YaST (SLES)

http://www.novell.com/developer/yast.html

(Internal) Virtualization Policy.pdf

Hello,

For one reason or another you might come into a situation were you are unable to login to the Symantec Endpoint Manager Console, Symantec provides a tool that helps to reset the admin password, this tool is placed by default in the SEP Manager installation folder which means you are required to have physical access to the OS  on which the SEP Manager is installed. in this guide i am going to walk you through resetting the admin password.

For versions below than Symantec Endpoint Protection 12.1 Release Update 1 Maintenance Patch 1 (RU1 MP1), you may like to use resetpass.bat utility.

The Symantec Tool is a batch file located in the following path “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Tools”

You can use the resetpass.bat to reset the password for the Symantec Endpoint Protection Manager admin account.

Note: If you change the admin account name to something other than admin and then run resetpass.bat, it changes the account name back to admin.

To reset the administrator password

     1. On the computer that runs Symantec Endpoint Protection Manager, start Windows Explorer.

     2. Go to the \Program Files\Symantec\Symantec Endpoint Protection Manager\Tools folder.

     3. Double-click resetpass.bat. The password is reset to admin.

     4. Change the password as soon as possible.

Note: If the account has been locked out due to repeated logon attempts, the resetpass.bat tool does not unlock the account. The default lockout period is 15 minutes.

Important Note: For the Symantec Endpoint Protection Enterprise Edition, do not use the admin account when setting up Active Directory Authentication. You must use a new Administrator account to use Active Directory authentication. For more information, see the knowledge base article, How to setup a SEPM administrator account to use your Active Directory authentication.

Check these Articles:

Resetting the administrator user name and password to admin

http://www.symantec.com/docs/HOWTO54992

Setting up authentication for administrator accounts

http://www.symantec.com/docs/HOWTO55479

Symantec Endpoint Protection 12.1 Release Update 1 Maintenance Patch 1 (RU1 MP1) or greater does not use resetpass.bat and it has been removed from the Tools directory.

If you have system administrator access rights for a site, you can allow your administrators to reset passwords. A password is reset by sending an email that contains a link to activate a temporary password.

Note: You can use this method to reset a password only for the administrator accounts that authenticate by using Symantec Management Server authentication. This method does not work for any administrator accounts that authenticate by using either RSA SecurID authentication or directory authentication.

Note: A temporary password can be requested only once per minute from a single Symantec Endpoint Protection Manager console.

For security reasons, entries are not verified on the server. To check whether the password reset was successful, you must check the administrator email.

If a mail server is configured, the mail server is used to send the email. If the email cannot be sent for any reason, the SMTP service is used to send the email. We recommend that you configure a mail server .

Hello Everyone,

By default when you do a install of Symantec Endpoint Protection Manager an 'admin' account gets created with full access and permissions to all areas of Symantc Endpoint Protection Manager.

You use administrators to manage your company's organizational structure and network security. For a small company, you may only need one administrator. For a large company with multiple sites and domains, you most likely need multiple administrators, some of whom have more access rights than others.

You can create additional administrators as per business requirement.

To add new administrator first time you need to login with 'admin' account.

Go to the Admin--> Administrators --> Add an administrator

In this demonstation I have created two more an administrators.

User1 - System administrator

User2 - Limited Administrator

By looking at an admin symbol you can gauge what kind of rights they have.

A limited administrator can be granted access to perform tasks within a single domain. These tasks include:

If logged in as an administrator then license tab & Domain tab will not be listed.

If you do not want administrator to manged the single site then you can remove that access as well.

Go to the Admin --> Administrator --> Edit an administrator, in this example Edit User1 an administrator --> Access rights --> Site rights-> Select 'Not authorized to manage this site'

Now user1 won't get an access to Server tab,License tab & domain tab, check this screenshot.

In this demonstation we have created 'User2' as a limitead administrator. User2 is allowed to only managed installation packages.

After login User2 will be only able to see Administrator tab & Installation package.

In the administrator tab he will be able to see only his own account.

Helpful Articles:

About administrators

http://www.symantec.com/docs/HOWTO55478

Managing domains and administrator accounts

http://www.symantec.com/docs/HOWTO55094

Adding an administrator account

http://www.symantec.com/docs/HOWTO55403

About access rights

http://www.symantec.com/docs/HOWTO55041

Configuring the access rights for a limited administrator

http://www.symantec.com/docs/HOWTO55037

How to change Manage Group permissions for Limited Administrators in SEPM for multiple groups.

http://www.symantec.com/docs/TECH92651

Which administrator activities are logged in the Symantec Endpoint Protection Manager console?

http://www.symantec.com/docs/TECH141668

About administrator account roles and access rights (Endpoint Protection 12.1.2)

http://www.symantec.com/docs/HOWTO81226

Hi all

I'm pleased to announce the availability of a Visio poster detailing Clearwell High Level Components.

In the Zip file you will find both JPG and Visio formats.

Regards

Dan

References:

[1]  Adding Patch Compliance Trending Capacity to SMP is as Simple as Running a Report Daily :D

[2] Connect downloads: {CWoC} Patch Trending Sitebuilder

Adding compliance by computer trending to your SMP

As you probably have seen here on Connect (if not check [1] and [2] first) we can do pretty graphs for compliance by updates / bulletin by gathering data from a single report [1], and the {CWoC} SiteBuilder [2].

Today we will add similar capabilities to the system, but to trend compliance by computer.

Now this is a very different matter, as we cannot possibly offer the option to list and display compliance by computer. Instead what we'll do is break out the estate by percentage. So we can list the variance on a given percentage value over time, and display the information in an efficient manner, with the current trend and historical max and minimums.

But before we get to the graphs, you'll need to create a SQL report and add the following query to it:

/* 
      COMPLIANCE BY COMPUTER TRENDING
*/
-- PART I: Make sure underlying infrastructure exists and is ready to use
if (exists(select 1 from sys.objects where name = 'PM_TRENDS2_TEMP' and type = 'U'))
begin
	truncate table PM_TRENDS2_TEMP
end
else
begin
CREATE TABLE [dbo].[PM_TRENDS2_TEMP](
	[_ResourceGuid] [uniqueidentifier] NOT NULL,
	[Computer Name] [varchar](250) NOT NULL,
	[Compliance] [numeric](6, 2) NULL,
	[Applicable (Count)] [int] NULL,
	[Installed (Count)] [int] NULL,
	[Not Installed (Count)] [int] NULL,
	[Restart Pending] [varchar](3) NOT NULL,
	[_DistributionStatus] [nvarchar](16) NULL,
	[_OperatingSystem] [nvarchar](128) NULL,
	[_StartDate] [datetime] NULL,
	[_EndDate] [datetime] NULL,
) ON [PRIMARY]
end

if (not exists(select 1 from sys.objects where type = 'U' and name = 'TREND_WindowsCompliance_ByComputer'))
begin
	CREATE TABLE [dbo].[TREND_WindowsCompliance_ByComputer](
		[_Exec_id] [int] NOT NULL,
		[_Exec_time] [datetime] NOT NULL,
		[Percent] int NOT NULL,
		[Computer #] int NOT NULL,
		[% of Total] money NOT NULL,
	) ON [PRIMARY]

	CREATE UNIQUE CLUSTERED INDEX [IX_TREND_WindowsCompliance_ByComputer] ON [dbo].[TREND_WindowsCompliance_ByComputer] 
	(
		[Percent] ASC,
		[_exec_id] ASC
	)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = 
OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

end

-- PART II: Get data into the trending table if no data was captured in the last 23 hours
if (select MAX(_exec_time) from TREND_WindowsCompliance_ByComputer) <  dateadd(hour, -23, getdate()) or (select COUNT(*) from TREND_WindowsCompliance_ByComputer) = 0
begin

-- Get the compliance by update to a "temp" table
insert into PM_TRENDS2_TEMP
exec spPMWindows_ComplianceByComputer
							@OperatingSystem = '%',
							@DistributionStatus = 'active',
							@FilterCollection = '311e8dae-2294-4ff2-b9ef-b3d6a84183cb',
							@StartDate = '1990-08-21T00:00:00',
							@EndDate = '2020-12-31',
							@pCulture = 'en-gb',
							@ScopeCollectionGuid = '01024956-1000-4cdb-b452-7db0cff541b6',
							@TrusteeScope = '{2e1f478a-4986-4223-9d1e-b5920a63ab41}',
							@VendorGuid	= '00000000-0000-0000-0000-000000000000',
							@CategoryGuid = '00000000-0000-0000-0000-000000000000'

declare @id as int
	set @id = (select MAX(_exec_id) from TREND_WindowsCompliance_ByComputer)

declare @total as float
	set @total = (select COUNT(*) from PM_TRENDS2_TEMP)

insert into TREND_WindowsCompliance_ByComputer
select (ISNULL(@id + 1, 1)), GETDATE() as '_Exec_time', CAST(compliance as decimal) as 'Percentile', COUNT(*) as 'Computer #', cast((CAST(count(*) as float) / @total) * 100 as money) as '% of Total'
  from PM_TRENDS2_TEMP
 group by CAST(compliance as decimal)
 order by CAST(compliance as decimal)

end

This is for the data gathering. You will notice that we only collect statistics for 100 entries, so this is even more scalable than the Compliance By Bulletin: it will take 10,000 run for the table to reach 1,000,000 entries.

Now, for the visualisation, a line graph would show the distribution of computers across a selected range, but we can use another Google Chart option: the candlestick.

See for yourself and let us now what you prefer, as the feature will go into version 0.6.8 of the SiteBuilder (out real soon):

Line chart:

Candlestick chart:

Note that the dataset only has 2 data columns right now, but as the base grows with time the candlestick chart will also show a vertical line going thru the  block center from the historical low and high values.

Also I have truncated the range to only include data from 75 to 100%, as it contains 94%+ of the estate.

For more on those chart, please see the Google live samples: https://google-developers.appspot.com/chart/interactive/docs/gallery/candlestickchart

In ServiceDesk 7.5 you have the ability to create incidents for yourself or any other user in the system. Once an incident is created the user who the incident is created for is called the Affected User.

Problem

Once an incident is created there is no functionality to change who the Affected User is associated with an incident. This leaves you with only two options. The first option is to close the incident and recreate the incident with the correct Affected User information. The second option is to add the correct Affected User as an additional contact on the incident and put notes into the case. Neither of these options is convenient or affective.

Solution

A new Workflow projected called SD.IncidentManagementSimple.UserManagement has been created to address this deficiency.

The project is designed to be setup as a Process Type action.

Project Overview

The SD.IncidentManagementSimple.UserManagement project was created to address a need for updating the Affected User information associated with a contact. This project incorporates the ability to add and delete existing contacts, as well as updating the Affected User.

Let's go over the main parts of the Manage Contacts form:

1. Displays the information for the Submitting user. This information can't be changed.
2. Shows the current affected user.
3. Text box for providing search criteria.
4. Shows the search results based on the search criteria and the option to add a found user as a contact. Please note that users who are already contacts on the incident (Submitting, Affected, or additional contact) are filtered out of the search results.
5. Displays any additional contacts on the incident and provides the ability to delete the contact.
6. Link to change the affected user.

Now let's go over the main parts of the Update Affected User form:

1. Shows the Current Affected User for the incident.
2. Search box to enter the search criteria to find users. Note that if the search box from the Manage Contacts form contains data when clicking on Change Affected User when the Update Affected User form loads it will automatically perform the search on the specified criteria.
3. Displays the found users based on the search criteria that you can set the Affected User to. Note that the search results will not include the information for the current Affected User.

Publishing the project and portal changes

Publishing the project

There are no special requirements for publishing the SD.IncidentManagementSimple.UserManagement project. You simply need to open the project inside Workflow Designer and publish the project as you would any other project.

Changes made in the Portal

There are two modifications that need to be made in the Process Manager portal. These modifications require administrator privileges to complete.

1. Define the new Process Type action
2. Hide the Add & Delete contact options in the Contact web part on the Process View page.

Defining the Process Type Action

1. Go to Admin-> Data-> Process Type Actions
2. Click the Lightning bolt for Incident Management and choose Add Action
3. Define the new Action as the screen shot below. If you wish to provide a different name for the Action that is fine. Also the screen shot shows I've defined a privilege level of 'Is Edit Action'. This means users will need to have edit permission on the incident to modify contact information.

4. Click Save

Modifying the Process Contacts web part on SD Incident Process View Page

1. Go to Admin-> Portal-> Manage Pages.
2. Expand Process View Pages
3. Select SD Incident View
4. Click the Go To Page button on the right.
5. Click Site Actions->Modify Page
6. Click Site Actions->Edit Page
7. Click the Edit button for the Process Contacts web part.
8. Uncheck the Show Add Button & Show Delete Button under the New Contact section.

9. Click OK

Symantec™ Protection Engine for Network Attached Storage replaces Symantec AntiVirus™ for Network Attached Storage.

Symantec Protection Engine provides virus scanning and repair services for a number of network-attached storage (NAS) devices. Symantec Protection Engine for Network Attached Storage features the Symantec™ Protection Engine, a carrier-class virus scanning and repair engine. The Symantec Protection Engine features all of the virus-scanning technologies that are available in Symantec antivirus products, making the Symantec Protection Engine one of the most effective virus solutions available for detecting and preventing virus attacks.

You can scan files for viruses automatically as they are accessed from storage before the requesting user gains access to it. Based on a configurable virus scan policy, when a virus is found in a file, the file is repaired. The clean file is stored on the NAS device and only then is the requesting user granted access.

Symantec Protection Engine uses the following protocols to interface with network attached storage devices:

• The Internet Content Adaptation Protocol (ICAP), version 1.0,as presented in RFC 3507 (April 2003)
• A proprietary implementation of remote procedure call (RPC)
• The Protection Engine native protocol

Each NAS device maintains a connection with Symantec Protection Engine to request scanning and repairing of files.

About software components

In most cases, adding virus scanning to a supported NAS device requires installation and configuration of the following components:

• Symantec Protection Engine, which provides the virus scanning and repair services
• Connector, which lets the NAS device communicate with Symantec Protection Engine

The connector handles the communication between the Protection Engine and the NAS device and interprets the results that are returned from the Protection Engine after scanning. The manufacturer of the NAS device develops and provides support to the connector. The connector typically is installed and configured on the NAS device. (In some cases, the manufacturer pre-installs the connector.)

The figure below shows a typical integration of a network attached storage device with Symantec Protection Engine.

1. The client tries to access a file on the network attached storage device.
2. The network attached storage device, by means of a connector, sends the file to the Symantec Protection Engine for scanning.
3. Symantec Protection Engine scans the file, repairs it if it is infected, and returns the clean file to the network attached storage device.
4. The network attached storage device writes the cleaned file to disk, caches the fact that the file has been cleaned, and sends the file to the client.

About the connector

The connector handles the communication between the Protection Engine and the NAS device and interprets the results that are returned from the Protection Engine after scanning. The manufacturer of the NAS device develops and provides support for the connector. The connector typically is installed and configured on the NAS device. (In some cases, the manufacturer pre-installs the connector.)

In some cases, no connector is necessary. The NAS device handles the communication with the Protection Engine, and any configuration options are available directly on the device.