diff -ru Email.pm /usr/local/lib/perl5/site_perl/5.8.9/RT/Interface/Email.pm
--- Email.pm 2009-10-19 15:55:31.000000000 -0400
+++ /usr/local/lib/perl5/site_perl/5.8.9/RT/Interface/Email.pm 2010-04-29 17:34:52.000000000 -0400
@@ -308,6 +308,7 @@
=cut
sub SendEmail {
+
my (%args) = (
Entity => undef,
Bounce => 0,
@@ -315,6 +316,7 @@
Transaction => undef,
@_,
);
+
foreach my $arg( qw(Entity Bounce) ) {
next unless defined $args{ lc $arg };
@@ -329,6 +331,13 @@
my $msgid = $args{'Entity'}->head->get('Message-ID') || '';
chomp $msgid;
+#### 4.29.2010 - custom hack to skip ticket number on support queue
+my $tSub = $args{'Entity'}->head->get('Subject');
+if ($tSub =~ m/^\[MyCompany's Customer Support queue #[0-9]+\] (AutoReply:.*)$/) {
+ $args{'Entity'}->head->set('Subject' => "[MyCompany's Customer Support queue] $1");
+}
+#### end custom hack
+
# If we don't have any recipients to send to, don't send a message;
unless ( $args{'Entity'}->head->get('To')
What should happen is that the RD session should drop after the application closes. What often happens is that the user sees a blue screen for up to two or three minutes, then the session completely drops.
I figured out the cause by using the Remote Desktop Services Manager. I launched a client session that launched the 32bit app upon login. I then closed the application, and the session hanged. Looking in the RD Services Manager, I noticed that there was a service from the session called "splwow64.exe." I killed that process, and the session dropped.
The Fix
The fix is pretty simple. It requires a regedit. Perform this regedit at your own risk! You should backup the registry before you start.
Navigate to the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs
Add the following 32 bit DWORD:
splwow64.exe
and set the value to 0
The fix worked instantly, at least for me. Your results may vary, of course. As far as I understand, you can create other dword values in there to terminate other programs that are stalling the exit of remote desktop sessions.
Apparently, splwow64.exe is used in thunking (in this context, converting memory addresses from 32 bit to 64 bit.)
| Pin 1 | Pin 2 | Pin 3 | Pin 4 | Pin 5 | Pin 6 | Pin 7 | Pin 8 | Pin 9 |
|---|---|---|---|---|---|---|---|---|
| x | black | yellow | brown | red (+green) | orange | white | blue | x |
I recently had to set up a remote nagios installation that would connect back to a central server via NSCA. I followed the standard Nagios documentation for distributed monitoring here. The passive service checks worked fine.
The problem was that I wanted passive checks for hosts, too, and not just services, as the central server would not be able to ping the remote hosts directly in the event that the data is considered stale. I set up all the checks on the central server side to be the service-is-stale check - so any staleness results in an alert, "the check data is stale." Unfortunately, the nagios documentation is a little vague about the ohcp command (the final paragraph on the nagios link above.) I couldn't find any real answer on passive host checks on the web, either.
