Windows Firewall strikes again…and again… Moving to Windows

newsletter
PGCG
Pretty Good Consulting Group
Got a problem?
EOM News and Views
Issue 38, Spring 2015
We create solutions.
Windows Firewall strikes again…and again…
We recently migrated a customer from an older version of EOM to EOM 11.0 on a virtual machine running Microsoft 2012 server.
Piece of cake: the service ran, the client could connect, and the configuration converted without incident. What did not work very well
was communication in and out of the server. First, receiving files from their production ClearPath was just not happening. We turned
on traces from the MCP side and could easily see that the ClearPath could not connect - yes, the name of the new EOM server was
correct; yes, we switched to the actual IP address and it still did not work; yes, we were able to ping from other systems. Finally it
dawned on us that we had not configured the Windows Firewall to let EOM traffic into the server. So, simply add a rule to allow
and all was well.
incoming traffic on port
Except for the remote EOM client, which could not connect. Ok, add a Windows Firewall rule on the EOM server to allow incoming
traffic on port
. Then all was well.
Except for the remote EOM client not showing useful Sentinel Alert Service statuses. It could not connect to the Sentinel Alert Service
on the EOM server. Ok, so (finally) add a Windows Firewall rule on the EOM server to allow incoming traffic on port
.
The easy way to determine if Windows Firewall is the culprit is to simply shut it off. If communications connections are successful
afterwards then you will be adding inbound and outbound rules in Windows Firewall once you turn it back on.
Moving to Windows Server 2012?
Windows Firewall ................ 1
Printing labels ......................... 2
EOM 12.0 style #s ............. 3
Combining Files..................... 4
Quick Hits........................................ 5
Contact information ........ 5
EOM 10.0 and above are officially qualified to run on Windows server 2012. Installing and
migrating from previous versions of EOM is usually not the problem - finding printer drivers
that install properly IS a problem. In previous Newsletters we noted that sometimes drivers
are just not available for newer operating systems. We also noted while installing drivers on
Windows Server 2012 we had to be logged in with a local account that was in the
Administrators group. That got us around one driver install issue last summer. This winter
we have run into a printer driver that just would not install. The first symptom is that a
new printer looks like it is about to install and then final dialog in the driver dialog sequence
loops (continuously). Loading the driver via the Print Server dialog box appeared to work,
but then the driver was not listed when trying to add a local printer. This driver installs
without incident on 2008 R2. Still under investigation . . . .
If you cannot find a driver or the known driver does not exist then you may be forced to
select a driver that does install and has very similar capabilities to the original driver.
How do I … ?
Printing labels with EOM is so easy that we rarely mention the capability. There is no obvious "how to print labels with EOM" and
unless you already know to look at the "Logical Page Attribute" you would not find anyting about labels in the EOM Help file. There
label examples in the demonstration files released with the software (Demo7 & Demo8), but you would have to dig a bit to see how
they worked. Even so, if you did not know about the EOM capability to assist with label output you still have an option: DDA - a
customer proved this is possible (but not recommended).
Recently we came across an EOM guru that wrote DDA logic to place data on label page. The label page was a typical 8.5 x 11 inch
page with 3 columns by 11 rows of labels. It was pretty cool - she selected data across multiple input pages and controlled the
output positioning with variables. Not only did the DDA keep track of the current column and row, but lines within that specific label.
Guessing that the time and effort it took to write & test the DDA was significant, it made us a bit squeamish to even mention the EOM
Logical Page Attribute - a much easier way to solve the problem . . .
The Print Attribute defines page properties - size of paper, margins, simplex/duplex, and so on. One of the properties within the Print
Attribute is the "Logical Page". The Logical Page simply gives you a method of slicing up that defined page into smaller "logical pages".
The reason this simplifies life so much is that you compose each logical page as if it were one {small} physical page - you do not even
have to think about where on the page you are actually writing data. The "slicing" is really easy: how many columns, how many rows,
and what order to write the logicial pages. A formfeed from the input data, "Lines per page" from the Print Attribute, or the DDA
command Perform Logical Formfeed moves to the next logical page on the physical page. When the last logicial page is printed on the
physical page EOM automatically goes to the first logical page on the NEXT physical page (which may be the on the back side of the
page when printing duplex or on the next piece of paper). The DDA command Perform Physical Formfeed ALWAYS moves to the next
physical page.
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
Label
EOM News & Views
Issue 38, Spring 2015
1:
1:
1:
1:
1:
1:
1:
2:
2:
2:
2:
2:
2:
2:
Line
Line
Line
Line
Line
Line
Line
Line
Line
Line
Line
Line
Line
Line
1
2
3
4
5
6
7
1
2
3
4
5
6
7
[2]
Page [ 2 ]
EOM 12.0 Ordering information
As before, the Windows version of EOM Department Edition will ship with the future ClearPath updates (ClearPath OS 2200 16.0 & ClearPath
MCP 17.0). Assuming your site has paid for the IOE subscription, you will receive the EOM 12.0 Department Edition as well as the current
host EOM software. All other pieces of the EOM release need to be ordered. Here are the style numbers and descriptions to do so:
EOM 11.0 Owners without subscription services:
Product
Department Edition
Enterprise Edition
Professional Edition
DDA/ DesignerWeb Assistant
DDA Designer
DDA Designer – Additional
New Upgrade License
DSS3120-UPG
DSS2120-UPG
DSS4120-UPG
DSS5120-UPG
DSS5120-DDU
DSS5120-D2U
SSU
DSU300-DPT
DSU200-ENT
DSU400-PRO
DSU500-ADM
DSU500-DDA
DSU500-D2
New customers or those with pre-EOM 11.0 versions:
Product
Department Edition
Enterprise Edition
Professional Edition
DDA Designer/Web Assistant
DDA Designer
DDA Designer – Additional
Component
DSS32-DPT
DSS32-CTL
DSS32-ESR
DSS500-ADM
DSS32-DDA
DSS32-DDA
New License
DSS3120-DPT
DSS2120-ENT
DSS4120-PRO
DSS5120-ADM
DSS5120-DDA
DSS5120-D2
SSU
DSU300-DPT
DSU200-ENT
DSU400-PRO
DSU500-ADM
DSU500-DDA
DSU500-D2
Secure Email:
Product
EOM Secure E-mail US
EOM Secure E-mail INTL
Component
DSS32-SED
DSS32-SEI
New License
DSS32-SED
DSS32-SEI
PDF Writer - which IS tied to the EOM 12.0 service:
Product
EOM PDF Writer
Component
DSS32-PDF
New License
DSS32-PDF
Highlights of the EOM 12.0 release can be found in the Winter 2015 Newsletter.
EOM News & Views
Issue 38, Spring 2015
[3]
Page [ 3 ]
Can EOM combine files for a single Print Job?
The question of combining incoming print streams to one Print Job has come up numerous times in the past, brushed aside by we ¤experts¤
without much additional thought. Sometimes desperate customers do not take ¤No¤ for an answer, so the following shows one method to
combine incoming files into one file before printing (or in this case creating a PDF file).
The customer had one or more files that just had to be combined before printing to a PDF file. AND, there could be multiple files to
combine throughout the data and even simultaneously combine different series of files. Since the files were sent via the LPD syntax we
could not use the name of the file to help segregate file series, nor could we use Print Queue since multiple files of the same type could
be created at the same time.
What they could provide however was the ability to add $DEPHDR$ syntax into the file(s). In addition, the application ¤knew¤ when the
series of files was complete so a ¤trigger¤ file could be sent to denote that the series was complete. Here is what the $DEPHDR$ syntax
looks like:
Where UserTag1 is the report name, UserTag2 is the date, and UserTag3 is the time (No, two reports of the same type could not run in the
same minute). When all of the report files to be combined are created, the ¤trigger¤ file $DEPHDR$ syntax with UserTag4 = ¤DONE¤ would
be sent in a separate (and empty) file:
The files to be combined call a Custom Job defined with the UCopyIt.exe program and the append (¤/A¤) option, so they are written into the
same file, in this example with the file extension of ¤.ttt¤. When the ¤DONE¤ UserTag4 is received it also runs the UCopyIt.exe program, but
simply changes the file file extension to ¤.ToPDF¤.
{Print data}
{Print data}
{Print data}
{Print data}
"<PCFILENAME>" c:\_CombineWorkingDirectory FN=<USERTAG1>-<USERTAG2>-<USERTAG3>.ttt /a
"<PCFILENAME>" c:\_CombineWorkingDirectory FN=<USERTAG1>-<USERTAG2>-<USERTAG3>.ttt FE=ToPDF /d
There are a couple of important settings to get all of this to work:
● The File Mask that identifies the ¤DONE¤ file references a File Group with a low Group Priority. This helps keep the final Custom
Job execution last if there are multiple Custom Jobs queued for the same series of files.
● There is a Directory Monitor watching for the final combined file, using the file extension (¤.ToPDF¤ in this example). The File
Mask that identifies files from this Directory Monitor is defined with a Print Job to a PDF printer.
● The application added a delay before ¤printing¤ the ¤DONE¤ file. This helps combine all files before processing the ¤DONE¤ file.
● There are potential holes in this solution that the customer is willing to live with.
EOM News & Views
Issue 38, Spring 2015
[4]
Page [ 4 ]
Training is available
If your team is looking for a brush up on features or want to know about
the entire EOM product we can help. Best of all is that we can use your real-life production requirements
during the custom training. The training can be accomplished remotely or on-site. We have to admit that
the on-site training usually is more beneficial in the long run because we tend to hear about (& see first
hand) more problems that EOM can solve.
Quick Hits
Who are we?
We have run into two different customer
experiences where
high volume of EOM
activity combined with remote EOM Client
connections cause the Windows TCP stack
on the EOM service server to ¤hose up¤. We
suspect that a very large number of Events
window messages along with a very large
number of File/Print Job Management
window
messages
overload
the
communication between the EOM service and
remote EOM client. BUT, we cannot prove
this as yet. To avoid the problem one
customer closes the remote EOM client
before processing a large set of files, and
the other switched to Remote Desktop to
open the EOM client on the EOM server.
Highly skilled, creative, solution provider
focused on the Unisys Enterprise Output
Manager product (formerly known as
DEPCON) with a sense of urgency sums up
who we are and what we do. We provide
general
Enterprise
Output
Manager
consulting,
migrations,
upgrades,
configuration,
training,
and
custom
programming.
On-site services, remote services,
general consulting are available now.
and
Why use PGCG? Deep knowledge of the
EOM product integrated into a variety of
customer environments set us apart. Our
customer’s production environment depends
on solid, working solutions that we provide.
DDA writers:
When using the
command remember to set
the ¤Command file is a font¤ to ¤Yes¤ if you
are using a PCL font call (i.e. 10cpi.pcl, or
calling an on-board MICR font).
Write
a brief description and send it to
[email protected] for
future newsletter discussion.
Pretty Good Consulting Group, LLC
4235 Ivy Court
Lake Elmo, MN 55042
www.prettygoodconsultinggroup.com
EOM News & Views
Issue 38, Spring 2015
[5]
Page [ 5 ]