Uploading those files from the appliance is very straightforward. Once the Service Request has been opened and the number has been provided to you, you can use the following procedure to upload files to Symantec support. **Please Note** All upload items are not required on all cases. Please use these instructions and upload the items that are requested in your specific case.
Open the web interface and navigate to Maintenance / Service Information / Send information / Send Service Information.
In the "Service Request Number" / Case box, enter the service request/case number in which you would like to upload files to.
In the New Edge SWG Admin Console
Administration- Service Information- Send Information- Send Selected Info Now- Click on Show Select and Send
In the Case number put the case number you would like to upload data
Here are the different options and what they represent
SYSINFO
The sysinfo is necessary for all support cases. It includes configuration (network, content-filtering, policy, licenses), hardware information (memory, CPU, network cards), statistics, and other important information
Event Log
The event log is also necessary for all support cases. It includes events and alerts that can give clues as to issues that might be occurring on the ProxySG.
SnapShots
By default, two snapshots are gathered by the ProxySG. The snapshot_sysinfo, taken every day, contains copies of the sysinfo taken over time. It is used to see if configuration changes happened during the past few days. The snapshot_sysinfo_stats, taken every hour, gather statistical information about resource usage. When a proxy becomes too slow, unresponsive, or crashes, the snapshot_sysinfo_stats is used to look at metrics taken while the proxy is not responsive or before the proxy rebooted. Because (by default) only 30 hours of statistics are gathered, it is important to upload the snapshot_sysinfo_stats a maximum of 30 hours after a reboot.
A technical support engineer might require a new snapshot to be created to gather statistics every 5 minutes when proxies go from normal operation to an abnormal state very rapidly.
Policy Trace
A policy trace shows how the proxy handled a request, how the rules were evaluated and if it was allowed or denied. This is important when trying to figure out why people are allowed/denied access to some web sites. Because policies are very flexible and very complex, a policy trace is often necessary in order to see which rules were triggered, skipped or bypassed by the connection.
Packet Capture
Examining a packet capture is necessary when users are experiencing problems accessing a web site, when they are prompted for authentication and they shouldn't, when the proxy is having DNS or TCP problems, or other scenarios where a connection was allowed but didn't work as expected. When both a packet capture and a policy trace are taken at the same time, it provides very valuable information for the support engineer troubleshooting the issue, which is why in many cases, a support engineer might ask for a policy trace to be configured and then a packet capture started before reproducing an issue.
Access Logs
Access logs might be required when troubleshooting an issue with Blue Coat Reporter or when the information reported in the access logs seems wrong. Because access logs files can get pretty big, it is usually not necessary to upload all the files. Usually a small section of a log is enough so an engineer might ask of you to copy/paste a few lines from an access log into an email. Only in rare cases it is necessary to look at a whole access log file.
Contexts
A context file contains information about a crash or a restart (even restarts initiated by an administrator). They contain information about processes that were running at the time the restart was initiated, some memory information, and in the case of a crash, information about the process that triggered the crash as well as CPU stack information. When looking for a root cause analysis on a crash, the context file will be requested
Memory Core
When a crash requires a deeper analysis by an escalation engineer, the memory core file will likely be necessary. It is a memory dump that was written before the unit crashed (in most cases). If the unit lost power, neither a context nor a memory core will be generated. A memory core file requires the Context file with the same time stamp to hold any value. The memory core alone cannot be used without its context, but a context can be used without a memory core. By default, the ProxySG does not produce a memory dump when rebooting because writing the content of the memory takes time which slows down the reboot process. You can set the option to write the file by going to Maintenance / Core images.
Full Core
The more recent units will produce a "Full" file when a crash occurs. This file is basically a context and a memory core all in one; this makes it simpler to upload the information over to support. Just like with memory core files, by default, the ProxySG will only generate a context file when rebooting. You can set the option to write the file by going to Maintenance / Core images.
