Closing the Console should actually only enable you to see the new
help files that were downloaded with the xpu (unless maybe there was
something weird going on with downloading the group file?). Depending
on what you're seeing specifically, there could be different issues
going on:
- Are you seeing the 24.3 folder, but just missing the events
underneath? This would indicate a corrupt policy, probably a policy
imported from a different SiteProtector or Workgroup Manager instance.
This is usually easy to fix, but please contact Technical support to
do it since it does involve manually editing the database to force a
reapplication of the policy xpu.
- Are you missing the entire 24.3 folder? This would indicate
something wrong with the NetEngineDefault.group file or the
ServerSensorDefault.group file (for your Network and Server sensor
respectively). This file is updated during the Network Sensor policy
xpu (the one called SPNS_POLICY_<Date>.xpu). Depending on what
version the database thinks its policy version is, it may or may not
apply the policy xpu when you apply a sensor update. The group file
is stored in three places:
- The BinaryData table in the database -- this is where the file
gets updated. You should never try to manipulate the files in the
database directly.
- \PF\ISS\RealSecure
SiteProtector\Console\SiteData\<app.server.ip.addr>\SupportFiles --
this is where the console downloads the group file. This is the copy
the console will try to use first. It's possible the console simply
hasn't downloaded a new copy. The console decides to download a new
copy of this file when 1) It detects a policy update has occurred and
you try to open a policy of that type (there's a setting in the
console.properties file for this), or 2) the setting in the
console.properties file afore mentioned has been deleted (i.e., new
console or first time opening a policy on a particular app server).
- \PF\ISS\RealSecure SiteProtector\Console -- The console uses this
file if it cannot find the above file. This file contains only up to
XPU 20.9, so if you are only seeing XPUs up to 20.9 then it may not be
downloading the file correctly.
Since there are three places, this means there are three places the
file could be incorrect -- since you should never make any changes to
the file in the root Console directory, and that file is just a
fallback anyway, this leaves two possible places where the file could
be wrong:
- The file is wrong in your SiteData\<app.server.ip.addr>\SupportFiles
directory -- perhaps the console didn't download it correctly?
OR
- The file is wrong in the database -- maybe the policy update didn't
even get applied?
You can find out which one it is by forcing the console to download a
new file, and looking in the new file to see if it has the correct
groupings or not. To do this:
1. Close out of your console.
2. Backup and Edit the following file with a text editor (please be
careful about editing any files manually -- messing up this file
without having a backup could possibly mean you have to reinstall your
Console):
\Program Files\ISS\RealSecure SiteProtector\Console\Config\console.properties
3. Locate lines which look like this:
iss.console.repository.LatestModifiedTime.BinaryDataType.<app.server.ip.addr>.4=1110472610373
iss.console.repository.LatestModifiedTime.BinaryDataType.<app.server.ip.addr>.7=1110909568000
iss.console.repository.LatestModifiedTime.BinaryDataType.<app.server.ip.addr>.8=1110909568000
These refer to the last download times for your response.policy file,
NetEngineDefault.policy file, and ServerSensorDefault.policy file
respectively.
4. To get the console to download new copies of these files, simply
remove the three lines mentioned above and save the file. You really
only need to remove the line of what you're trying to redownload, but
it's usually easier just to take them all out at once.
5. Reopen your console and attempt to reopen a policy. Depending on
the type of policy you chose (Server or Network sensor), you should
see the console has downloaded a new .group file to your
SiteData\<app.server.ip.addr>\SupportFiles directory. Verify that it
did indeed do this.
6. Locate the file for the type of policy you edited. For example,
say you edited a Network Sensor policy -- look for the
SiteData\<app.server.ip.addr>\SupportFiles\NetEngineDefault.policy
file. Open this file with a text editor and scroll to the bottom to
verify it contains sections for 24.3 (you should see sections for all
the other XPU groupings as well).
If the file does contain the 24.3 grouping, then your issue is resolved.
If it does not, and you're SURE it downloaded a new file when you did
the procedure above, please call Tech Support since the procedure to
reapply a policy update can get sticky depending on whether your
database thinks the policy update has already been applied or not.
The only time we usually see this kind of thing happen is when someone
moves their fully updated sensors to a completely new SiteProtector
instance which has not yet had the policy updates. The console will
show that no updates are available because you have already updated
your sensors. If this is the case, you would just be able to roll
back and roll forward the xpu for one of the sensors for each sensor
type. Honestly, it depends on the policy version in the database.
(i.e., not hard to fix, but not something I'd recommend you do without
help since it involves manual editing of the database, which always
has the potential to break the database if not done correctly)
_______________________________________________
ISSForum mailing list
ISSForum@iss.net
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo/issforum
To contact the ISSForum Moderator, send email to mod-issforum@iss.net
The ISSForum mailing list is hosted and managed by Internet Security Systems,
6303 Barfield Road, Atlanta, Georgia, USA 30328.
