14.2.1 Windows:  Installing the script

Once you have downloaded the files, you can unpack them into any convenient directory, preferably one that is in your PATH.  For instance, you may prefer to install them in a directory called C:\%USERPROFILE%\PROC, or even C:\PROC.  If you are installing the files directly onto the LISTSERV machine, you may even unpack them into \LISTSERV\MAIN if you so choose.  The most important point to observe is that LCMD.EXE and LCMDX.EXE must be available to the script, so they must be either placed in the same directory with the script or found somewhere in your PATH.

Note: It is likely that you will have to unblock the script before PowerShell will allow it to be executed.  This can be done in one of two ways:

    • Open a PowerShell prompt, change to the directory where you have unpacked the files, and execute “Unblock-File gdprscan.ps1”; or

    • Right-click the gdprscan.ps1 file in Windows Explorer, choose “Properties”, click the “Unblock” button found at the bottom of the “General” tab

14.2.2 Windows:  Named Pipes or TCPGUI?

You will need to decide whether GDPRSCAN will be using LCMD.EXE (which is a named-pipes interface) or LCMDX.EXE (which is a TCP/IP interface that talks to the TCPGUI port on the LISTSERV machine, in a similar manner to the way the WA interface works).  

Note: If you are using the script to pull GDPR reports from a unix LISTSERV site, you must use LCMDX.EXE, as the named-pipes interface used by LCMD.EXE is only useable with the Windows version of LISTSERV.

The interface is chosen by specifying an optional value for the -Method (minimum abbreviation:  -m) parameter on the command line.  Either

-Method LCMDX


-Method LCMD

can be used.  The default is “LCMDX”.

Typically, the named-pipes interface will work only if the machine running the script is in the same Windows domain as the LISTSERV server machine, and you have not explicitly disabled named pipes on either your Windows client machine or the LISTSERV server machine, and so long as named pipe connections are not otherwise blocked from either end.  You may also need to make a minor configuration change to LISTSERV, as by default, named-pipe requests are presumed to be coming from invoking_userid@NODE – for instance, john.doe@LISTSERV.EXAMPLE.COM.  This may or may not be what you want.  You can use LISTSERV's CMDPIPE_HOSTNAME= site configuration variable to change the hostname side of the address.  For instance, if your enterprise addresses take the form of local_part@EXAMPLE.COM, you could set CMDPIPE_HOSTHAME=EXAMPLE.COM and restart LISTSERV to pick up the change.

The advantage to using named pipes is that the LISTSERV named pipes interface is secure and does not require password authentication.  If password authentication is desired, or if you are using the script to run GDPR reports on a machine that is external to your local Windows domain, or is running on a unix machine, you will have to use the LCMDX.EXE TCPGUI interface instead.

14.2.3 Windows:  Where to write the XML report?

By default, GDPRSCAN will write the resulting XML report to your Windows desktop.  This may or may not be optimal for you, so there is an option to change it.  If you wanted to change it to your "My Documents" directory, simply use the -XMLpath (minimum abbreviation: -x) to set it accordingly:

-XMLPath 'C:\Users\youruserid\My Documents'

14.2.4 Windows:  Executing the script

Once you have installed the script and made any needed changes to the LISTSERV configuration, you will execute the script like this (optional command line arguments shown in square brackets []):

With LCMD (Named Pipes):

PS C:\PROC > .\gdprscan.ps1 -s listserv-hostname -t target-email [-d ALLlists | SYSTEM | FULL]


PS C:\PROC > .\gdprscan.ps1 -s listserv-hostname -t target-email -p postmaster-email [-d ALLlists | SYSTEM | FULL]

When using the script with LCMDX, you will have to provide one additional pieces of information to the script after running it – the LISTSERV personal password corresponding to the postmaster-email address you are using.  The password is obtained securely (see the examples below) and is stored as a secure string while the program is running.

Example using the PowerShell ISE:

Example if executed from a PowerShell prompt (not the ISE):

Example if executed from a Windows command prompt:

The script will continue to execute after you hit <return>.

The final command line argument is optional, defining the depth of the changelog scan.  For a normal (default) scan, this argument is not used.  Changelog scanning levels are defined as follows:

Default (no argument)

Only the listname.changelog files for the lists to which the target email address is subscribed are scanned.


(minimum abbreviation: “ALL”) All listname.changelogs are scanned, regardless of whether the target email address is subscribed.  (This may pick up information on lists to which the target email was subscribed in the past.)


Same as the default, plus SYSTEM and NOLIST-* changelogs are scanned, if present.


All changelogs on the server are scanned.

If specified, these levels are mutually exclusive; only one may be specified per run.  

The options are presented above in ascending order of how much time they will typically take to execute.  On one L-Soft server, the ALL option resulted in a 51-minute-long scan for a single user; however, significant network latency may have contributed to that test.  Another L-Soft server with a very large SYSTEM.CHANGELOG processed the ALL option for a single user in 15 minutes.

Typically, scanning changelogs other than those belonging to the list(s) to which the target address is subscribed is an expensive operation, there may be little if any personal information for the target address found in them, and it may simply not be desirable to run that deep of a scan.

GDPR does not require data controllers to spend an unlimited amount of time on requests, and therefore, L-Soft has left the decision on depth of scan up to the customer.