Now the spam creators (whoever they are, burn in hell!) have come up with something new. Something I cannot stop!, something that pisses me off! PDF attachments.
The Microsoft IMF filter is a cracking little freebie with a nice way of stopping things manually included. Along with the IMF Companion this is all we have needed so far in the endless battle against spam.....until now.
How exactly d you stop PDF attachments with the IMF filter?
Monday, 30 July 2007
Monday, 23 July 2007
MAC addressing in VMWare
After too many hours spent doing support calls and not enough time free to look at infrastructure we decided to pull a late night and Saturday working in order to get some things done out of normal hours.
The fact that each hour out of normal hours is worth about 5 hours in work time meant that we had time to look at some issues that had been hanging over our heads. Do a few installs and look at some left over servers from the virtualisation push earlier in the year.
First up was the DDM server. We thought this would be problematic as we wanted to virtualise it BUT still use the existing licenses on the server. Design Data Manager itself has its own licensing system built in using a web front end. The licenses themselves are MAC address locked. Due to the way that VMWare worked with its failover system MAC locking is problematic.
If a ESX server fails for whatever reason or is under stress VMWare has some clever load balancing available to allow the server to move (whilst staying up) to another ESX server in the cluster. As you can imagine moving the virtual server also moves the NIC that the server is running on. MAC addressing would be interesting to say the least....
We BartPE'd the server using Ghost peer-to-peer and then tried the Windows method of manually setting the MAC address in the driver of the network card:
Pulling up Pro-ENGINEER on the client didn't work, DDM ran like a charm using the same license but it appears as though FlexLM doesn't look at Windows for its information and was picking up an ESX MAC address starting 00:50:56. This code is still some ESX jiggery-pokery and not the REAL MAC address of the NICs in the server so although FlexLM ignores the windows change it couldn't get right to the hardware.
It looks as though we are going to have to get new license codes for the VM server using the ESX MAC address and then set the server so that it doesn't move. This of course has its downsides but I guess that the FlexLM software didn't want people getting free software by copying their friends MAC addresses onto their card in Windows.
The fact that each hour out of normal hours is worth about 5 hours in work time meant that we had time to look at some issues that had been hanging over our heads. Do a few installs and look at some left over servers from the virtualisation push earlier in the year.
First up was the DDM server. We thought this would be problematic as we wanted to virtualise it BUT still use the existing licenses on the server. Design Data Manager itself has its own licensing system built in using a web front end. The licenses themselves are MAC address locked. Due to the way that VMWare worked with its failover system MAC locking is problematic.
If a ESX server fails for whatever reason or is under stress VMWare has some clever load balancing available to allow the server to move (whilst staying up) to another ESX server in the cluster. As you can imagine moving the virtual server also moves the NIC that the server is running on. MAC addressing would be interesting to say the least....
We BartPE'd the server using Ghost peer-to-peer and then tried the Windows method of manually setting the MAC address in the driver of the network card:
Pulling up Pro-ENGINEER on the client didn't work, DDM ran like a charm using the same license but it appears as though FlexLM doesn't look at Windows for its information and was picking up an ESX MAC address starting 00:50:56. This code is still some ESX jiggery-pokery and not the REAL MAC address of the NICs in the server so although FlexLM ignores the windows change it couldn't get right to the hardware.
It looks as though we are going to have to get new license codes for the VM server using the ESX MAC address and then set the server so that it doesn't move. This of course has its downsides but I guess that the FlexLM software didn't want people getting free software by copying their friends MAC addresses onto their card in Windows.
Monday, 9 July 2007
IMF XML Custumweights
Despite my good work from the previous entry the IMF filter failed me. Not through any fault of its own mind you.
The IMF filter runs from Microsoft Update and as I stated in my previous post it creates a new folder for each update deleting any folders except the latest 3 so you can roll back in time. It also reregisters the DLL from the latest update so its all nice and tidy....however.....
What it doesn't do is copy over the customweight XML file. What this means is despite your best efforts to stop certain emails using the XML it won't work when the new update comes in and you have to manually copy the XML file into the newly created directory.
I came in today and found that Saturday saw a nice IMF update come in and lo and behold my users now have an inbox full of 'US NMA' mails!
Copied over the file, restarted the SMTP service and now its blocking them again....anyone how this could be scripted?
The IMF filter runs from Microsoft Update and as I stated in my previous post it creates a new folder for each update deleting any folders except the latest 3 so you can roll back in time. It also reregisters the DLL from the latest update so its all nice and tidy....however.....
What it doesn't do is copy over the customweight XML file. What this means is despite your best efforts to stop certain emails using the XML it won't work when the new update comes in and you have to manually copy the XML file into the newly created directory.
I came in today and found that Saturday saw a nice IMF update come in and lo and behold my users now have an inbox full of 'US NMA' mails!
Copied over the file, restarted the SMTP service and now its blocking them again....anyone how this could be scripted?
Thursday, 5 July 2007
US NMA and IMF2
After a couple of days of spam from 'The United States National Medical Association' trying to sell us drugs online from an everchanging variety of email addresses I decided to investigate why these things were getting through even though we had the Exchange SP2 IMFv2 installed and enabled.
First up I added the required entry to the MSExchange.UceContentFilter.xml file (add opening and closing brackets and slash as required):
Make sure you save this in notepad in the unicode format or you can get application log errors and a failure to work regardless of getting the rest of this right.
Then I did a restart of the SMTP Virtual Server from within the Exchange admin tool. Back to gmail and a little test to my internal mail, straight to my mailbox.
Not to be deterred I had a quick rummage around the net regarding IMF not working. According to a fellow blogger the IMF although getting updated automatically with the required registry entry was basically creating a new folder structure each time an update was installed.
Looking at the folder structure I could see 3 different versions in the IMF folder. Another interesting point was that the XML file had to be in the version that you were running (IMFv1 ran from the IMF folder proper). So I copied the XML file into the newest folder.
Penultimately you had to make sure that the correct DLL was registered, one was in each version folder and one in the root presumably from the old IMFv1 days. So I ran a:
First up I added the required entry to the MSExchange.UceContentFilter.xml file (add opening and closing brackets and slash as required):
customweightentry type="SUBJECT" change="MAX" text="The United StatesNational Medical Association"
Make sure you save this in notepad in the unicode format or you can get application log errors and a failure to work regardless of getting the rest of this right.
Then I did a restart of the SMTP Virtual Server from within the Exchange admin tool. Back to gmail and a little test to my internal mail, straight to my mailbox.
Not to be deterred I had a quick rummage around the net regarding IMF not working. According to a fellow blogger the IMF although getting updated automatically with the required registry entry was basically creating a new folder structure each time an update was installed.
Looking at the folder structure I could see 3 different versions in the IMF folder. Another interesting point was that the XML file had to be in the version that you were running (IMFv1 ran from the IMF folder proper). So I copied the XML file into the newest folder.
Penultimately you had to make sure that the correct DLL was registered, one was in each version folder and one in the root presumably from the old IMFv1 days. So I ran a:
Still nothing so I did a restart of the SMTP Virtual Server, no dice so finally did a restart of the SMTP service....and....HUZZAH! We now have blocking again.regsvr32 C:\Path To Exchange\BIN\MSCFV2\6.5.7931.0\MSExchange.UceContentFilter.dll
Tuesday, 3 July 2007
Event 6161
We have another printing problem. This time with Remote Desktop users.
They can add printers to there RDP profile fine and the driver appears to have installed correctly with all the HP bumf included so I don't think this is a driver specific issue.
When they print to this printer they get an event 6161 in the system log and the document fails to print. Trawling of Google has done little to fix this problem at present so if anyone has a fix drop me a comment.
The error is 31 which equates to 'a device attached to the system.....' its a bugbear for so many issues in Terminal Services so I am kind of clueless at the moment.
Everything works fine for admins so this looks to be some sort of rights thing somewhere.
They can add printers to there RDP profile fine and the driver appears to have installed correctly with all the HP bumf included so I don't think this is a driver specific issue.
When they print to this printer they get an event 6161 in the system log and the document fails to print. Trawling of Google has done little to fix this problem at present so if anyone has a fix drop me a comment.
The error is 31 which equates to 'a device attached to the system.....' its a bugbear for so many issues in Terminal Services so I am kind of clueless at the moment.
Everything works fine for admins so this looks to be some sort of rights thing somewhere.
Subscribe to:
Posts (Atom)