The connection to the TMCM server fails when using HTTPS with MCP proxy of HTTP protocol
To avoid connection issue, you must connect directly or use HTTP proxy.

This is a normal behavior of IE and SharePoint. When downloading a cleanable file, it will first be cleaned and then a virus found report will be generated. Afterwards, IE will use the link to this report for downloading. If you selected Save target as, IE will be directed to this link and will prompt a virus found report.

There are three (3) types of Domain Group: Universal, Global, and Domain local. The Domain Local Groups are used to assign permissions to groups and/or users to use a specific resource, such as printer or share. As for PortalProtect, we will not use such type of groups.

The account to launch the setup.exe file must be the domain admin or must be the same as that of the account in the target machine.

In a domain ENV, an administrator is treated as domain name\administrator by default. Therefore, if you want to log on as a local admin, you have to input hostname\administrator as the username.

This happens when you install PortalProtect with another DB access account which is different from that of the account deploying SharePoint.

By default, SharePoint content DB will be accessible to the DB account that deploys SharePoint. If PortalProtect is installed with another DB account, the account must be configured to have reader role to config DB and owner role to all the content DB. Otherwise, the manual scan cannot access all the content DB, which causes some scan failures.

You can use the same DB access account, which is used to deploy SharePoint, to install PortalProtect.

When you are trying to remotely install PortalProtect to target servers located in another domain in the same forest, you are unable to run setup.exe on a machine in one domain.

The current design requires you to use the same domain account to run setup.exe and to log on to the remote target servers. There is no available account for two different domains. You will have to run setup.exe on a machine in the same domain with the remote target servers.

PortalProtect can no longer scan files which have been scanned by the previous engine/pattern.

PortalProtect should notify SharePoint that there is a need to rescan by writing the SharePoint registry. However, SharePoint does not periodically read the registry key unless "Windows SharePoint Services Administration Service" is running.

This is a SharePoint design. The files in the recycle bin or version history are not exposed to PortalProtect manual scan. Therefore, previous infections in a file's version history or infected files sent to the recycle bin will not be scanned. However, since content of the recycle bin or version history can only be accessed after it is restored, the restored content will be scanned and protected.

It is a SharePoint behavior that when receiving incoming email with infected attachment, SharePoint will send several files with different names to PortalProtect scan module through virus scan hook. This is why you have 3 logs.

This issue happens when the files being uploaded trigger some rules. The messages appear all right in the SharePoint web site but appear truncated in WebDav. Examples of these messages are "[BLOCK" or "[QUARANTINE". The last character "]" and succeeding texts are lost.

Web-based Distributed Authoring and Versioning (WebDav) is a set of extensions for HTTP that allows users to edit and manager files on remote World Wide Web servers.

It is a WebDav behavior to truncate the text after "]".

When generating a zip package file, different zip software may choose different encoding methods to store the filenames in the package. Some software may use fixed encoding (such as UTF-8) while others may select the encoding according to the current system locale of the OS (such as Windows ANSI code page on Windows). In other words, filenames stored in different zip packages may use different encodings.

PortalProtect cannot handle all the different encodings which causes the file block function not to work in some scenarios.

This happens when the Office12 files exceed the Scan Restriction Criteria in VS. Essentially, Office12 files are zipped/compressed files. Therefore, if they exceed the Scan Restriction Criteria, PortalProtect will take the unscannable action.

There are instances when users need to change the location of the database file. For MS SQL servers, it is as simple as changing the location. However, for PortalProtect, you will need a configuration key with the location of the DB files. There is a need to change the config file of dbcfg_InstallPath.txt.

By default, Windows 2008 firewall blocks "File and Printer Sharing", but it is needed to perform remote installation. You will not be able to install PortalProtect if this option is not enabled.

A user may change the shared resource pool's path but the former hook processes may still try to re-register the new shared resource files with the new paths. This could be possible since they use the same resource pool-ID as former to register. However, if the former registered resource pool, with the pool-ID, has not been closed and deleted, then the new shared resource pool file information will not be recorded and registered in PortalProtect Master.

Later on, unexpected behavior may happen when scanning contents in the new shared resource pool files with the PortalProtect Master trying to retrieve the content from the old shared resource pool files.

It is actually an abnormal behavior to change the shared resource pool path. PortalPortect cannot block non-English file names in a zip file.

After installing PortalProtect, the only way that it can notify SharePoint of its availability for scanning is to write the SharePoint registry. However, SharePoint does not periodically read the registry key unless the "Windows SharePoint Services Administration Service" is running.

There is a need to add in the GSG that users need to enable the "Windows SharePoint Services Administration Service".

This issue can happen when the report folder is removed or encrypted. We use system sml library to analyze report xml file. If the report folder cannot be accessed, the system API will fail. There is no workaround for this issue at the moment.

SharePoint has system files with Office 2007 Excel as file types. When users configure a real-time scan or manual scan to block such file types, such files will be blocked or deleted. There is no workaround for this issue yet.

SharePoint has some special list types, such as calendar, tasks and announcements. Users can attach files to these kinds of lists. However, when the files are infected, PortalProtect will scan and block or quarantine the attached files. There is no workaround for this issue yet.

This issue is caused by SharePoint sending several files with different names to PortalProtect scan module through virus scan hook. There is no workaround for this issue yet.

The PortalProtect master service account can be local system and the domain user depends on the deployment mode. For service account as local system, the user can change the system local format and then apply it to the account. No workaround is available, however, for service account as domain user.

When downloading a cleanable file from SharePoint with version history enabled, the version history files will not be scanned. However, the actual file will be scanned by PortalProtect.

SharePoint will try to combine the version history file and the actual file whenever the file is being accessed. Therefore, PortalProtect always sees infection for the combination which causes the download to fail. This issue also applies to the files in SharePoint's recycle bin. There is no workaround for this issue yet.