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 [email protected] TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo/issforum To contact the ISSForum Moderator, send email to [EMAIL PROTECTED] The ISSForum mailing list is hosted and managed by Internet Security Systems, 6303 Barfield Road, Atlanta, Georgia, USA 30328.
