Although my old machine still has the connection setup I was not able to see the cached/saved password. Although it is possible to export the sites, the password remained encrypted and I wanted to document the actual password.

There are a lot of tools, some free and some which you have to pay for which will recover the cached FTP password for you. Some of these looked a bit questionable and as FTP is an entirely unencrypted service I thought it should be easy to sniff the password out of the FTP traffic itself.

Turns out that it really is very easy and the saved password can be retreived instantly using netmon.

So here is how to do it.

Create a new capture filter in netmon and enter the following:

tcp.Port==21 and property.TCPPayload.contains("PASS")

Should look like this:

Then click on the start button to begin capture. Then open your FTP client which contains the cached password and connect to the FTP server.

As soon as you have made a succesful connection switch back to netmon and stop the capture. You should then be able to see the FTP password in clear text in the capture window, something like this:

I spotted a lot of posts from people trying to recover or export their saved FTP passwords from CoreFTP and CuteFTP and many programs are designed specifically for this purpose. This is quick and simple and does not depend on any 3rd party software and should work with any FTP client.

Hope this helps someone.

Final error: 0xe00084c8 – The backup storage device has failed.
Final error category: Backup Device Errors

For additional information regarding this error refer to link V-79-57344-33992

And then…

Final error: 0xe00084c8 – The backup storage device has failed.
Final error category: Backup Device Errors

For additional information regarding this error refer to link V-79-57344-33992

In the application event log there may also be the following:

Event Type: Error
Event Source: Backup Exec
Event Category: None
Event ID: 33808
Date: 06/02/2010
Time: 19:02:25
User: N/A
Description:
An error occurred while processing a B2D command.
Drive: ReadMTFData() ReadFile failed (N:\VERITAS\B2D\B2D001024.bkf). Error=1450

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

Event Type: Error
Event Source: Backup Exec
Event Category: None
Event ID: 57665
Date: 06/02/2010
Time: 19:02:25
User: N/A
Description:
Storage device “Friday N:” reported an error on a request to read data from media.

Error reported:
Insufficient system resources exist to complete the requested service.
.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

Data:
0000: aa 05 00 00 c8 84 00 e0 ª…Ȅ.à
0008: 00 80 00 00 00 00 00 00 .€……
0010: 92 03 00 00 ’…

Event Type: Error
Event Source: Backup Exec
Event Category: None
Event ID: 34113
Date: 06/02/2010
Time: 19:02:25
User: N/A
Description:
Backup Exec Alert: Job Failed
(Job: “Friday – Backup to N:”) Friday – Backup to N: — The job failed with the following error: The backup storage device has failed.

For more information, click the following link:

http://eventlookup.veritas.com/eventlookup/EventLookup.jhtml

A lot of people have this problem but there seemed to be no definitive answer. For me the following steps solved the problem:

1) From within device manager set the USB drive to “Optimize for performance”:

2) From within Backup Exec Devices – Set the maximum size for Backup-To-Disk files to 2GB

3) From within Backup Exec Devices – Disabled auto-detect device settings and enabled “Buffered Reads” and “Buffered Writes”

There is no clear resolution for this problem. Different settings seem to solve the problem for different systems. This is running on a Dell PowerEdge 2850 / Windows 2003 Standard and 4Gb. Backup size is approx 250Gb.

Telnet to the router:

Default username is Administrator (note the capital A)
Default password is empty

Then run:

service system ifadd name=PING_RESPONDER group=wan

You should now be able to ping the wan address.

Mailbox Role
Failed

Error:
An error occurred. The error code was 3221684229. The message was Access is denied..

Simple fix for this is to run setup.exe in compatibilty mode. I chose Vista SP2 and then the installation went through normally.

But before you go rushing to finish your installation it is worth noting that Exchange 2007 SP2 will not be supported on Windows 2008 R2, and therefore you may want to reconsider doing the installation at all! Read here:

http://msexchangeteam.com/archive/2009/09/21/452567.aspx

I flattened the installation and went back to Windows 2008 Standard.

Update: Microsoft have changed the policy to support Exchange 2007 on Windows 2008 r2:

http://msexchangeteam.com/archive/2009/11/04/453026.aspx

After the installation of SP1 the user was not able access the corporate VPN.

When trying to connect Vista hangs at "Verifying username and password" and eventually shows an 828 error.  On the server side event 20209 was logged.

There is a discussion on the ZA forums as to where the blame lies for the problem but there does not seem to be a clear answer.

For the sake of simplicity, I have found that:

On Vista SP1 machines with version 7.1.248 of ZoneAlarm free installed PPTP VPN connections to Windows 2003 Based RRAS servers do not work.  Also note that disabling ZoneAlarm does not help.  Uninstalling the product solved the issue immediately.

Always a pain when you try to solve one problem and create another in the process.  On a positive note Terminal Services easy print in Windows 2008 worked really well once we got the user reconnected.

Looking around the blogs, these e-mails seem to be having a higher than normal infection rate. It is time consuming to get rid of and makes the infected machines unusable and creates a huge number of network connections.

The exact subject line of the email’s that have been received is:

UPS Tracking Number 5440074870

Attached to the e-mail is a zip file containing an executable which when executed installs "XP Security Center".

Much more information about the detail of the actual email can be found on the Trend Malware Blog.  The worrying thing about this e-mail is that both of the machines that it infected have their e-mail filtered by very well known external 3rd party mail systems, then have virus scanning on their own Exchange servers and finally on their desktop machines.  At the moment this e-mail is still slipping through the net.

This virus does a LOT of clever things to prevent you getting rid of it.  I noticed that when trying to run Autoruns from Sysinternals that it just would not work.  Renaming the autoruns executable allows it to run.  It also stops you being able to install/download Windows Defender, disables system restore, removes the system tools program group amongst other things.

Not a very sophisticated solution but for now I have edited the Exchange IMF custom weighting file on customer systems to ensure that messages with "UPS Tracking" in the subject line are never delivered to the recipients and definitely classed as spam. 

I had written a separate post on how to remove the virus manually, but at the moment I am still monitoring the infected machines to ensure they are completely clean.

The reason for this was because their IP address had been listed on the CBL.

I had a poke around the server and everything seemed to be in good order; patched up to date, virus scanner had nothing interesting to report, netstat did not show any abnormal connections and Exchange queues seemed normal. So I assumed that the problem must be coming from one of the network PCs.

This customer has a dual nic SBS 2003 Standard edition server, not my preferred set-up, but the system had to be implemented in this way to fit in with existing infrastructure. It is not possible to see what traffic is passing through the NAT gateway on RRAS with the built in tools, but Microsoft Netmon 3.1 should be able to show up any strange network traffic. I installed it and ran the following filter:

Tcp.dstport == 25 and ipv4.Address != 192.168.200.1

192.168.200.1 is the IP address of the internet facing NIC on the SBS machine.

Within a couple of minutes this filter showed all the machines on the network sending SMTP based traffic except for the SBS server itself. Fortunately there was only one. I took remote control of the machine and from the command line ran:

netstat -ano |find ?��Ǩ?�:25?��Ǩ�?

The output of this command showed me the local processes which were attempting to communicate with other hosts on port 25 and gave me confirmation that this PC was definitely infected with some kind of mass mailing virus or worm. Killing the process listed by the netstat command stopped the mass mailer and gave some breathing space to find the cause of the problem.

Turns out the machine in question had its virus checker disabled. So I turned it back on and ran a full scan which turned up almost 6,000 files infected with W32/MyDoom.

Once the problem had been found it was easy to sort, but because I have so few customers with this set-up it had not occurred to me how little visibility you get over network traffic with the SBS 2003 standard edition tools.

The joys of travelling sales laptops

It sends an e-mail to a specified recipient reminding them to change the backup tape in a server. The SBS backup system does this automatically, so this is meant for use on SBS servers using something other than the in-built SBS backup.

Installation is simply a case of extracting the contents of this zip file to a folder on your SBS server and then changing the variables at the top of the script to appropriate values for your environment.

Once done you can test interactively from a command line by running “cscript tapereminder.vbs” and once you are happy with the results setup a scheduled task to do the job daily.

As most of the machines I manage are SBS boxes I thought that it would be nice to put something together which behaves in much the same way as the SBS generated e-mail alerts.

So, the result is a script which sends e-mail notifications to a specified address and gives details of which patches are available to be installed.  The administrator can choose which of the four patch levels will trigger an e-mail alert (Critical, Important, Moderate & Low).

If there are no outstanding patches at the appropriate alert levels to be installed then the script will quit without sending an e-mail.

The script is then run as a scheduled task every evening and I can quickly see if I have anything to action.  The report includes links to the relevant KB articles and further information made available by Microsoft.

The script only takes a couple of minutes to setup as there are only six settings at the top of the file…

Setting any of the following to 1 will generate trigger alerts for that particular update severity:

• AlertCritical
• AlertImportant
• AlertModerate 
• AlertLow
  
• EmailFrom – Specifies the e-mail address the report will be sent from.
• EmailTo – Specifies the e-mail address to send the reports to.

As shown above I have been running with AlertCritical/AlertImportant set to 1 and the other two set to 0. 

So, if you want to receive email alerts all you need to do is download this Zip file, extract the contents to a folder on your server and then edit the variables at the top of the script.  To perform a test run go into a command prompt and change directory to the location where you extracted the script and run:

cscript winupdates.vbs

With any luck you should get an e-mail soon after with the results.  If you find that it is not generating you an e-mail as expected, one reason may be that there are no patches available to install.  Bear in mind that not all items from Windows update will appear.  For example “Internet Explorer 7″ is not a patch and therefore will not be listed.

Running the script interactively as above will take a few moments while Windows Update(or WSUS if you have it installed) are checked for new updates. 

Once you have completed a successful test you can go ahead and setup a scheduled task.  Assuming an installation directory of “c:\scripts” the scheduled task command should look something like this:

C:\WINDOWS\system32\cscript.exe c:\scripts\winupdates.vbs

Also worth a mention that I have used this on standard(non-sbs) Windows servers and it works well.

Perhaps if enough people use this script, it will actually save as much time as it took to make it, but I doubt it.

In this, more basic example the entire message is saved to the filesystem in .eml format to a folder specified within a variable. The script could be made much more elaborate with the addition of a couple of arrays to specify multiple subjects/locations. The idea is that you could setup a system where e-mails can be automatically filed without having to depend on user intevention and avoiding the requirement for 3rd party software.

This can be implemented by following the example from this Microsoft Knowlegbase article. The file referred to in the article called SMTPREG.VBS can be found here on MSDN. Instead of the SMTPMsgCheck.vbs file referenced in the article create a file called SMTPSubjectCheck.vbs and insert the following code(you will also need to modify the registration batch file accordingly) :

<SCRIPT LANGUAGE="VBScript">
Sub IEventIsCacheable_IsCacheable()
	'To implement the interface, and return S_OK implicitly
End Sub

Sub ISMTPOnArrival_OnArrival(ByVal Msg, EventStatus )
	Dim Pos, SubjectToFind, SaveFolder, MsgStream

	SubjectToFind="Project1"
	SaveFolder="c:\\"

	Pos=InStr(1,Msg.Subject,SubjectToFind,1)

	if Pos <> 0 then
		set MSGStream= Msg.Getstream
		SaveFile=SaveFolder & Msg.Senton & "-" & msg.subject & ".eml"
		SaveFile=Replace(SaveFile, "/", "_")
		SaveFile=Replace(SaveFile, " ", "_")
		SaveFile=Replace(SaveFile, ":", "_",3)
		MsgStream.SaveToFile savefile,2
		MsgStream.Close
		Set MsgStream = Nothing
	End if
End Sub
</SCRIPT>

In this example the script is looking for a subject line that contains the text “project1″(not case sensitive) and saving it to the root of c:

I have attached a zip file to the blog post with all the required files in one zip file, just be cautious of using it if you already have event sinks registered(drop the files into c:\eventsink).
subjectcheck.zip