WSS Block executables into zip file

I need a solution

Hello everyone

I need you help, in my portal of WSS I do a rule to block all executable files *.exe, according this KB

The rule work fine, but if the file *.exe is compress in file *.zip don´t work

Any idea of ​​why it does not work like that?


Andres Garcia



  • No Related Posts

Secure Mail: How to edit the MDX file for enabling/disabling the hidden policy.

Following are the steps for enabling/disabling Android hidden MDX policy:(Please take a backup of the .MDX file prior to making any changes)

1. Rename the .mdx file that you have to a .zip file

2. Unzip it, open the policy_metadata.xml file and look for the policy, here we take “Auto_Populate_username_title” as an example.

3. Change the PolicyHidden tag to true or false.

User-added image

4. Now, select all the files in the folder that has xml and apk tag, along with various properties files, and compress them (To compress we will have to go inside the folder, select all the files -> send to -> Compressed ).

5. Rename the compressed .zip file to a .mdx file

6. Upload this mdx file on your environment

XenMobile How Do I


  • No Related Posts

UCD version import from artifactory adding artifactId+version parent directory

I am importing a component version to UCD from a zip file in artifactory, the UCD component is configured to unzip the archive file in the basic settings.

When viewing the component version in UCD after the import, i find that a parent directory named [artifactId].[version], which happens to also match the name of the zip file in artifactory, has been added to the archive contents in UCD. Is there a way for me to configure the import process to not add this parent directory to the UCD component version’s path?


  • No Related Posts

Error by importing modified project as ZIP in WKS

I have exported annotated corpus from WKS and try to replace annotated text with the translated text in all documents (sets, documents and individual docs in GT). All other text stays untouched. But after doing that I can’t import zip into another project – getting an error:

> A file could not be imported: The imported ZIP file is not in the expected format. Check whether the file was exported from another project. The type system from the same project must be imported first. (You selected ‘Import corpus documents and include ground truth’).

What’s wrong with my zip?


  • No Related Posts

StoredIQ generates empty report


Our Customer has a problem with generating CSV all audited objects export on infoset. Firstly, we have started report which was running for about week and could not finish. Later we run it successfully for the second time, but the report was empty. In fact we have checked cd /var/siq/download and .zip file size was 22 bytes.
Is there a way to troubleshot it or just should be run another time?
Infoset size was about 30 GB.


InsightIQ Blog – IIQ Tools

Hello everyone in the Isilon-land,

I was helping a customer who experienced time-outs during a lengthy datastore import process. I figure I’d share the problem and the proposed solution here as a blog.

Problem: The problem is that the datastore import/export functionality in InsightIQ v3.2 uses the tar.gz format to compress the exported datastore. The tar.gz compression format cannot be indexed to speed up the importing process. As a result, some large, long-running import process can time out.

Solution: A Dell EMC engineer in the Global Services team (customer support) wrote a tool to tackle this problem. Essentially the tool allows for unpacking of the tar.gz datastore export and repack it into a .zip format, which allows for indexing. Importing a datastore using the .zip format has shown to greatly speed up the import process, and thus reducing the potential of timeouts during import.

If you are currently running an old version of InsightIQ (v3.2), the database structure behind the datastore is based on PostgreSQL, same as the current version of InsightIQ (v4.1.1). There is also no database schema changes from v3.2 to v4.1.1. You should be able to use this utility to import a re-packed datastore export into InsightIQ v3.2. But if you are intending on deploying the current version of InsightIQ (v4.1.1), I would perform this unpack/repack/import process AFTER you’ve raised your InsightIQ v4.1.1 instance, using the repacked export from v3.2.

The utility is located here:

The documentation page is located here:

The utility you care about is this one:

Pasting the “readme” section here:


Starting with InsightIQ 3.2, you could export a cluster’s database from one instance, then import it later or on another InsightIQ instance. Initially, the exported data was in tar file format, but in InsightIQ 4.1 we switched to using a zip file. The switch was to resolve a bug where importing large exports would time out. The data contained within the tar and the zip files is identical; only the compression format has changed. This means that if we convert an old tar export to zip, we can use that archive in newer versions of InsightIQ.

Use cases for this script:

Migration Upgrades

Instead of upgrading an existing deployment, you export the data on your old instance, use this script to convert the format, and then import that data on a new deployment of InsightIQ. This approach is ideal for OVA deployments of InsightIQ because the newer OVAs for InsightIQ have the latest security patches applied, and the root partition is configured with LVM.

Maintain Legacy Exports

With the upgrade to 4.1, any datastore exports created on the older version of InsightIQ are no longer compatible. This script will update the format of those older datastore exports so you can continue to use them in newer versions of InsightIQ.


  • No Related Posts