Sembee Blog

I wanted to update my Windows 7 installation DVD so that it not only installed any version of Windows 7, but also both the 64 bit and the 32 bit. It would be used on both a memory stick and DVD. 

While searching around the internet, I found various techniques using various third party tools. However as I didn't have any of the third party tools and wasn't about to buy them for this single task, I found my own way of creating the DVD using tools that Microsoft have already provided. 

Requirements

• Windows 7 ISOs/DVDs of 64 bit and 32 bit. Doesn't matter which version, as long as it isn't Starter Edition. I probably wouldn't use a vendor supplied disk either as you never know what changes they have made to it. MDSN, Technet or Retail will be fine. 
• Windows 7 Automated Installation Kit. This is a free download from Microsoft here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34&displaylang=en  - this file downloads as an ISO - hence the need for an ISO mount tool. 
• An ISO mount tool.
• Optional: A virtual machine platform to test on. 

Method

1. Create two temporary directories. One called WIM and one called DVD. 
2. Mount each ISO in turn and copy the file "Install.WIM" to the directory "WIM". Rename the file that comes from the 32 bit DVD/ISO x86.WIM and the one from the 63 bit DVD/ISO x64.WIM
3. Copy the entire contents of the 32 bit Windows ISO in to the directory called DVD. 
4. Delete the file "ei.cfg" from the copy of the DVD that you have created. This is the file that locks the installation media to a specific version of Windows 7. If it isn't present, setup prompts you for the version you wish to install. 
5. Install Windows 7 AIK - this is the option "Windows AIK Setup" when you run StartCD from the downloaded ISO.
6. With the Windows 7 AIK installed on your computer run the Deployment Tools Command Prompt.
7. Type the following commands in the Command Prompt window. Change the  paths and drive letters to match where you have stored the files.
   Alternatively, copy all of these commands in to a notepad document, rename the document run.bat (or whatever you like) and run that instead.
   IMAGEX /Export E:\WIM\x86.WIM 5 E:\WIM\INSTALL.WIM "Windows 7 Ultimate x86"
   IMAGEX /Export E:\WIM\x64.WIM 4 E:\WIM\INSTALL.WIM "Windows 7 Ultimate x64"
   IMAGEX /Export E:\WIM\x86.WIM 4 E:\WIM\INSTALL.WIM "Windows 7 Professional x86"
   IMAGEX /Export E:\WIM\x64.WIM 3 E:\WIM\INSTALL.WIM "Windows 7 Professional x64"
   IMAGEX /Export E:\WIM\x86.WIM 3 E:\WIM\INSTALL.WIM "Windows 7 Home Premium x86"
   IMAGEX /Export E:\WIM\x64.WIM 2 E:\WIM\INSTALL.WIM "Windows 7 Home Premium x64"
   IMAGEX /Export E:\WIM\x86.WIM 2 E:\WIM\INSTALL.WIM "Windows 7 Home Basic x86"
   IMAGEX /Export E:\WIM\x64.WIM 1 E:\WIM\INSTALL.WIM "Windows 7 Home Basic x64"
   IMAGEX /Export E:\WIM\x86.WIM 1 E:\WIM\INSTALL.WIM "Windows 7 Starter x86"
8. Copy the new install.wim created above in to the \Sources directory of the DVD directory created in step 3, replacing the existing. 
9. Back in the Deployment Tools Command Prompt, run the following command:
   oscdimg.exe -lWindows7 -m -u2 -b"E:\DVD\Boot\etfsboot.com" E:\DVD E:\Windows7.ISO
   Where 
   
   • Windows7 is the name of the DVD (note the lack of space between the l and the name),
   • E:\DVD is the source directory
   • E:\Windows7.ISO is the destination ISO name. 
10. Test the ISO using VMWARE Player or other VM technology, before burning to DVD. 
11. For memory stick use, simply take an existing USB memory stick used for installing Windows 7 and copy the Install.WIM file created above and replace the existing. It will then support both. 

Networking General Networking General

This is part two of a three part case study of a recent network rebuild I carried out. For part one - click here: http://blog.sembee.co.uk/post/Case-Study-2-Part-1-Network-Rebuild-Intro-and-Workstations.aspx 

Servers

Now to the interesting bit. 

The server design was in my head for months, and then got completely redesigned following the client wanting to go with my suggestion of replicating the data off site. 

What we had was two HP ML350s, an old IBM and a HP desktop as the BES server. 

What we ended up with is three DL380s, two on site, one in the datacentre. 

All three DL380s are running VMWARE vSphere 4.1. 

VM1 - Two Windows VMs - a DC and a SQL Database server and a Linux based firewall. 

VM2 - Three VMs - a DC, Exchange 2010 and an application server. 

VM3 (in the data centre) - a DC, Exchange 2010 and a SQL database, plus a Linux based firewall.

As we are going to replicate Exchange data using a Database Availability Group, we needed to use Windows 2008 Enterprise edition. As Enterprise edition allows multiple installations of Windows on one physical machine, I decided to split up the functions in to dedicated servers. 

Furthermore, with more and more software products using SQL, and the client using SQL for an internal task, a dedicated SQL server was used. 

All three servers lived on the same network for a week, before the third server went off to the data centre. 

Data Replication

For real time data replication of the file structure, the network uses the latest version of DFS, built in to Windows 2008 R2. This works very well. 

For replication of Exchange data, a DAG is used for mailbox data, and native Public Folder replication. 

For SQL, this is mainly in the form of a backup, which is replicated to the data centre server shortly afterwards. Nothing the client does requires live replication of the SQL data. 

Exchange

Being an Exchange MVP, the design of the Exchange part of the platform was quite important, and everything has worked as I expected. 

The server that lives in the data centre is the only one that is exposed to the internet. All email comes in and leaves through that server. This provides a number of key benefits. 

• In the event of a loss of the main office, all email is coming in to a server that is under our control. We don't have to worry about email bouncing or being lost. 
• The dependency on the ISP at the main office is also removed, which I discuss further in part 3 networking. 
• Spam filtering is being done on the faster bandwidth available in the data centre.
• I have also pointed OWA and Outlook Anywhere traffic at the data centre server, not only for speed reason but if we have to use a backup internet connection, the clients don't have to be touched. This means that all inter-server traffic goes over the WAN connection. 

An RPC Client Access array is configured for outlook.example.local which points at the local CAS server, but allowing for easy changes in the event of a full failure. 

We also updated the Blackberry Enterprise Server from a very old version 4.0 to a 5.02 Express server. This is installed on the application server, with its database on the SQL server. 

Other Bits

WSUS - there are two WSUS servers in place, with the workstations pointing at a server in their office, and the laptops pointing to a child WSUS on the Exchange server in the data centre. This means that the laptops can pull their updates straight from Microsoft, whereas the desktops pull theirs from the local WSUS server. This saves bandwidth. 

As we had to use Windows Server Enterprise edition, which allows the use of four virtual machines, the server in the data centre had a spare. Therefore I have built a web server. Installed SmarterStats on to the server, which can only be accessed from the internal network. This means the client was able to change their public web site hosting arrangement and save money there. 

SmarterStats also allows use of OWA to be tracked. 

For backups, we dumped tapes, and Backup Exec. Switched to two Iomega Network Attached drives, with the backup job controlled by Backup Assist. The drives are exchanged each day, but are being used for archive purposes only. For full scale recovery, the copy in the data centre would be used. Shadow Copies is also enabled to provide additional levels of security.

The VMWare platform is managed by a vCenter server installed on the application server, with monitoring provided by Veeam's monitoring application. 

Remote access to the site is available via Log Me In, Remote Desktop Gateway and VPN. There is also the option of accessing the network resources with their Blackberries. This came in very handy when I couldn't remember a password in the data centre and needed to look it up on the password database (SecretServer from Thycotic) which has a mobile interface. 

Server Conclusion

In effect, the client now has their own mixed cloud and on site implementation, just they aren't sharing anything with anyone else. Data is stored off site, in real time. Traffic from the internet comes in through a static location which is secure, and fast. The client almost has a complete business continuity plan for a lot less than they would ever dream of. 

Part Three - Network is here: http://blog.sembee.co.uk/post/Case-Study-2-Part-3-Network-Rebuild-Networking.aspx

Amset IT Solutions Ltd. / Sembee Ltd., Case Study, Exchange 2010, MS Exchange Server, Networking General Amset IT Solutions Ltd. / Sembee Ltd., Case Study, MS Exchange Server, Networking General, Exchange 2010

Very occasionally, you get to do a job which you really enjoy. Being able to put lots of things that you have learnt over time in a single client deployment and make a very satisfying job. 

At the end of 2010 I completed just such a deployment.  

I could go on for hours about this deployment, as there are so many little things that were done, which I haven't had the chance to do before, or just make it a much better network. As I have complete control over the network, and have done for some time, I can ensure it runs exactly as it should. 

Only 40 users, so enough to use networking kit with. 

First, some background. This particular client is my oldest client. I have had them since about week six of my company. 

Just over 5 years ago I rebuilt their network, replacing their servers with a new domain, and all workstations were rebuilt. This was the first time I could try the locked down workstation method, as they had no proprietary or awkward third party application that "required" admin rights to run correctly. All desktops, and the one laptop didn't leave the building. 

Windows 2003, Exchange 2003 at the back end, on three servers, two HP and a very old clunky IBM which died last year. 

Clients were Windows XP, Office 2003. 

However it was starting to show its age. Three hours to setup a new workstation was becoming a joke, and the cost of server maintenance was getting higher all the time. 

Therefore it was decided that it was time to change the lot, all in one hit. 

Yes, you read that correctly. On the Monday they had the above, by the end of the week it was all changed. 

The first question then is how we could get away with doing a big bang change like this. 

It wasn't the original plan. I was looking at maybe changing the servers this year, then the workstations next. Office 2010 had just been released when planning started. However there was a keenness to do more, introduce laptops for some mobile workers so it was decided to make the change all at once. 

Furthermore, because the workstations were locked down, and were a basic build (Windows XP, Office 2003, AV, and a terminal application), with all relevant data redirected to a server, the amount of work that the move required would be minimal. The key company application is a database system that runs on Unix (which fortunately I have nothing to do with). The workstations are basically an office document and web browsing station. 

Then in a planning meeting I just happened to mention that we could replicate all of their data off site in real time for a lot less than they thought. So replacing the two servers became three, with replication thrown in as well. 

So this and the next two blog postings are a quick overview of what was done. If you would like to see it in action, and want me to do the same for your company, please let me know (UK Only). 

I am going to divide the rest of this blog in to three - workstations (below) and servers and networking which will have separate posts.

Workstations

This is quite easy. 

During the last 12 months of the previous XP/2003 based network, all replacement workstations were bought with the upgrade in mind. Minimum of 2gb of RAM and Windows 7 licences where possible. 

However a number had to be replaced, plus for the first time an active laptop fleet was introduced. 

This initial preparation work though made the initial deployment much easier. 

Desktops were Windows 7 Pro, Office 2010, Adobe Acrobat Reader, AV. The flash player was installed fresh, plus the terminal application. Installing off a memory stick, I was turning each machine around in about 45 minutes. 

Laptops were Dell Latitude, software as above. However we also added built in 3g cards so the users could work anywhere. Part of the plan (which I am not involved in) is to provide a web based access to their core database and inventory system. 

I also suggested, and was taken up, that every user, from the CEO down, was given a mandatory training session. So each staff member did a half day on Windows 7 and Office 2010. We found a local trainer, who created a bespoke course for the client. I explained what I wanted them to know. 

It should be pointed at this point that a large number of staff in this client are rather mature - I think I am still one of the youngest in the building when I go to visit. A change from Windows XP to Windows 7 would be quite different. The training was not only to show them how to do things, but also to simply give them confidence that they wouldn't break it. 

Therefore they were trained how to change the wallpaper, jump lists, gadgets. A brief overview on internet security and the like. They were trained on their actual workstations, so after the training was complete, there was a frantic period of machine change rounds. This meant that when they returned to their desks, things that they had done during training were still there. I felt this was important for adoption of the new platform. 

The new laptop users were given a slightly different course, which gave them a grounding in looking after the laptop. For most of them, this was the first time with a laptop. 

The client operates a conveyor belt system with desktops. New desktops go to the power users, with the slower ones going down the food chain, before eventually being removed. Therefore we started training with the power users on new desktops, while their older machines were rebuilt for the next session, and so on. This meant that during the training sessions I was rebuilding machines the users had just left. It got rather frantic. 

I rebuilt 9 machines in one day at one point, and put in 11 hour days four days on the trot. 

The end result though is that the client now has a complete desktop and laptop fleet that is on the latest OS and Office version, locked down, with the benefits that brings from a management and security point of view. 

In Part Two, I shall go over the server configuration. http://blog.sembee.co.uk/post/Case-Study-2-Part-2-Network-Rebuild-Servers.aspx 

Amset IT Solutions Ltd. / Sembee Ltd., Case Study, Exchange 2010, MS Exchange Server, Networking General Amset IT Solutions Ltd. / Sembee Ltd., Case Study, Exchange 2010, MS Exchange Server

Back in June 2009, I blogged on an authenticated user attack on a client's server.
http://blog.sembee.co.uk/post/Usernames-Tried-During-Authenticated-User-Attack.aspx

As part of that blog post, I included the list of names that were attempted.

The same server was attacked again in the last few days, and the list of usernames attempted changed very slightly. I have included the list below.
So quaint that they were tried in alphabetical order as well.

This list, along with the list from the original attack should be a list of usernames and passwords that you should avoid using, simply to ensure that you don't expose more than is necessary to this kind of attack.

www
vm
visitor
user
testuser
test
sysadmin
sysadm
support
supervisor
sales
operator
office
marketing
mail
info
guest
fax
backup
anonymous
admin
adm
account

MS Exchange Server, Networking General MS Exchange Server, Networking General

Something I have been doing frequently for the last 18 months of so is cleanups of SBS 2003 servers and their associated networks. I have a number of clients in the IT Support industry who ask me to clean up their client's servers. Two of them get a new client and the first thing they do is ask me to look at it and make recommendations.

In many cases it is minor cleanups or ensuring that everything is up to date. However one that I have done just recently deserves a blog posting on its own.

Background

New client for one of my IT Support clients.
They said that their client didn't think that there had been much maintenance done by the previous support company and the AV had expired. They were also looking to use Windows Mobile devices but were having problems getting it to work.
It had already been agreed to deploy AVG, so I was asked to look at the site and report what was required.

Seven users, one server, low level of email use apparently. Old school was the phrase that was used to me when describing the company.

I was shocked, to say the least.

Server

SBS 2003 RTM.
Thankfully I was sitting down when I saw that. No service packs, no automatic updates nothing.
DHCP was being run by the router, not the server.
DNS wasn't configured correctly.
The AV had indeed expired - 18 months ago. It was Symantec as well.
POP3 connector for email collection
Most of the wizards hadn't been run correctly.
Various other bits of junk on the server
The backup wasn't configured correctly, therefore the Exchange transaction logs were building up. There were four years of transaction logs.

Clients

I was able to get on to one of the clients.
Windows XP SP1
Office 2003 RTM
Same expired Symantec AV.
Adobe Acrobat Reader 6 (remember that?).

It was like the site was stuck in 2004. The site was deployed and never touched afterwards.

Anyway, I like a challenge.
Did I mention that the site was 350 miles away, and I was working on it remotely?

The positives?
I tried.
8mb ADSL getting 5mb on the bandwidth tests, which was ok. Plus it had a static IP address. The server had lots of space on it, it was a good configuration, multiple arrays, 2gb of RAM. It was a Dell system and the original suppliers had obviously installed it fresh as it didn't have the Dell issue of a 12gb root partition. However the rest of the server hadn't been done correctly.

So what did I do?

To begin with, over a course of two nights in the week, I downloaded the updates I needed

Windows 2003 SP2
Exchange 2003 SP2
Windows XP SP2 and SP3
SBS SP1
SharePoint Service Packs
WSUS 3.0 SP1
Office 2003 SP3
AVG Admin and the main Application
Adobe Acrobat 9.0

I asked my client to purchase an SSL certificate credit from https://DomainsForExchange.net/
I also asked for access to their domain name configuration, and web site.

Finally I asked that all the workstations be left on over the weekend and a tape left in the backup drive.

Before I started, I corrected the backup job.
This not only provided me with a backup of their data, it also flushed out almost 15gb of transaction logs, which made the server a little more snappier. Once the job was finished, I ejected the tape as a precaution.

With a successful backup, I could then begin the real work.

I started off by flashing the router firmware to the latest version, then reviewing its configuration.
Then started on the server, downloading the latest BIOS and drivers.
Windows Service Pack was first, then the driver updates.
Rest of the service packs as required, concluding with the WSUS installation. I then set that to sync and started on the workstations.
Symantec AV was removed and the AVG installation was setup and configured, ready for installs on the clients.

I moved the data around on the server as per the best practices.
Using the SBS Best Practises tool, cleaned up any issues that flagged and reset the backup job to backup correctly. 

Each workstation had the Symantec AV removed, the Adobe Acrobat removed and then was brought up to SP3. Rebooted as required.
Office 2003 service pack installed along with the new version of Acrobat Reader.
The workstations also got updated BIOS and drivers.

AVG was installed on the systems, updated and a full scan carried out.
They were very lucky. While a few things were found, they were not serious and

I setup the client with an OpenDNS account and changed the configuration of the server to use that. DHCP was removed from the router and moved to the server. However before I did that I carried out an IP Address scan and found a network printer. A nice HP LaserJet. Fortunately it was configured by defaults, so I was able to connect to it, update its configuration and firmware. Then downloaded the latest drivers from HP and installed them on to the server and shared the printer from there. On each client the printer was changed from direct to the shared printer.

The SSL certificate was deployed with a real name following some DNS changes, and the relevant port opened on the firewall (443). Yes I know SBS can do that for me, but I needed to retain control.
Configured a split DNS system so that the external name on the SSL certificate also worked internally.

I also downloaded and installed PRTG Traffic Grapher and configured that on the server to look at the router. Created a mini admin web site on the server, with PRTG on a web page, along with the AVG status page and a web page to manage the IMF quarantine emails.

By this time WSUS had synchronised, so a few group policy changes had the client talking to that. I ran a few scripts on the client to get them to call in correctly, then left them to download their updates for a few hours.

Once the updates were in and installed, and the systems rebooted, close to finishing.
Secured the server for SMTP email and then changed the MX records to point to their static IP address.

Tested Exchange ActiveSync from outside, along with RPC over HTTPS, OWA and confirmed it was working.

Finally set all systems to defrag. 

There were also a lot of very small changes that I do on every site which are simply too numerous to list (plus I can't remember them all).
I was also available on Monday morning for any issues that came up - there were none.

Rough tests on start up times of the server and workstations showed that I halved the time they took to start up.

The job took most of a weekend and basically involved three or more years of maintenance being done on the network in that time. Once it was complete I dropped an email to my client with a list of what I had done (pretty much what I written above), recommendations for future work and a bill for £2,000.

Probably the best bit was the feedback from the end users. It felt like they had a new network, everything worked, faster, things we where they should be etc. Overall everyone was very pleased.

Ultimately, they were lucky. As they had a router and their email traffic was so low, they didn't get hit by anything major that would have caused a problem. They were badly exposed though and if something had got in then it would have run amok.

The Sales Pitch

If you are in the UK and either a direct user of SBS or are supporting SBS Servers, then I can do something similar for you. Server cleanups start from £250 (+ VAT) depending on the work that is required. I will look at the server and tell you what is needed and quote on that basis. Additional bits (like SSL certificates, AV licenses etc) need to be purchased separately.

If you are a support company, then this type of work can give you a quick win and provide you with an immediate impact with the client. The simple change from POP3 connector delivery to SMTP delivery is normally enough, without the other background work.

In the vast majority of cases, this work can be carried out remotely, out of hours. It does not require a site visit, simply remote access is required (Log Me In is my preferred method).

Similar work can be carried out on the full product over multiple servers.

However, here is the interesting bit… the financials.
The client who I did this job for was prepared to buy additional hardware and software from their previous support company to resolve the problems - which the previous support company had caused by not doing the maintenance correctly. Someone suggested getting a second opinion, and that has saved them money. Their original outlay will now be fully utilised and they will see benefits. Since that work was carried out in mid September they have started to use Windows Mobile, and are now looking at laptop use. Productivity has increased - simply by investing some time in their existing infrastructure, rather than purchasing new and going through the headache of a migration. Despite everything I did for them, Monday morning they were able to come in and start work immediately, with no significant impact on their business, other than the "wow" factor.

Exchange 2003, MS Exchange Server, Networking General, Amset IT Solutions Ltd. / Sembee Ltd., Small Business Server Exchange 2003, MS Exchange Server, Networking General, Amset IT Solutions Ltd. / Sembee Ltd., Small Business Server

As you should be aware, certain directories on an Exchange server should be excluded from scanning by antivirus products.
These are Microsoft's recommendations on which directories those should be:
Exchange 2007: http://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx
Exchange 2003: http://support.microsoft.com/kb/823166/
Exchange 2000: http://support.microsoft.com/kb/328841/

However if you have setup the AV software as per the recommendations, how do you know that it is working, or more importantly it is not scanning things you have told it to exclude?

The best way to do this is to use the EICAR test file. This is a standard file that all AV vendors support that can be used to simulate alerts.
You can download the file from here:  http://www.eicar.org/anti_virus_test_file.htm

Simply copy the file in to the same directories as your Exchange databases or whatever else you have asked the AV product to exclude. If it is ever detected then the AV product is scanning things that it shouldn't be.
If you have set the product to exclude file types instead (For example edb files) then change the extension to edb. If the AV product has been configured correctly and is following that configuration then it should ignore it.

Of course the problem will be putting the file in place initially, particularly if you have already deployed the AV software. In that case setup a directory exclusion on a special directory for the purpose and create the EICAR file there instead. After copying the file to the relevant location, delete the exclusion.

Exchange 2003, Exchange 2007, MS Exchange Server, Networking General Exchange 2003, Exchange 2007, MS Exchange Server, Networking General

Last year I wrote about how I was caught out with detecting Vista in login scripts (http://blog.sembee.co.uk/archive/2007/01/06/31.aspx).

Following the release of Service Pack 1 for Windows Vista, I was caught out again as the version number has changed. In my login scripts I use the output of the command "ver" to detect the operating system.

With Windows Vista RTM it was 6.0.6000. With Windows Vista SP1 it is 6.0.6001. Therefore any login scripts that detect Vista need to be updated to include both version types.

This is easily done and should not mean too much additional code.
If you have used the method in my examples and put the script commands in to sections, you simply need to add a line to the detect the later version:

findstr "6000" %systemdrive%\ver.txt
if not errorlevel 1 goto vista
findstr "6001" %systemdrive%\ver.txt
if not errorlevel 1 goto vista

:vista
rem vista commands here

By grouping them together the same commands can be used for both RTM and SP1 versions of Vista, unless you need to use different commands for the different versions.

Networking General Networking General

One of the worst experiences for an Exchange administrator is to come in one morning and find that either email is being blocked, the queues are long or the users are getting NDRs saying that the server is blacklisted.

This seems to result in confusion amongst administrators who then go looking for advice only to get conflicting answers on what the problem might be.
I am going to try and clear up some of that confusion which should help Exchange administrators find the source of the problem.

There are two main issues that Exchange administrators seem to see and fail to understand.

1. There are a large numbers of messages in the queues.
2. The IP address of the server has been blacklisted.

In both of these occasions many administrators seem to think that a client machine on their network has been compromised and is sending email through the Exchange server.

This is not the case.

To abuse an Exchange server in this way, a BOT writer would need to

1. get the BOT inside the network
2. infect the machine
3. realise that it is on a corporate network where there is an Exchange server
4. find the Exchange server
5. send the message.

The above, is not going to happen - at least not at the moment. Too much like hard work. The first two are the most difficult - if the network security has been configured correctly and the users trained to recognise potential suspect emails or web sites.

Then sending the message requires either a MAPI interface or SMTP to be configured on the Exchange server to allow users to relay through the server. While this is default, if you do not have any users who need to relay through the server (Outlook, OWA and Windows Mobile/Blackberry BES users do not need to) then you should disable it.

Then for a successful infection and abuse, the above is also presuming that the user is an administrator and the network admin will not notice the infection!

What the BOT writer is really looking to do is infect clueless home users who are not keeping their machines patched, not using security software and are running as a local admin. Much higher chance of success there involving simpler techniques.

Therefore with the target in mind, the BOT will usually have its own SMTP engine and will be sending out email directly to the internet.

So what has happened?

If you have been blacklisted but the queues are clear, then a client machine has probably been compromised. This is often the case when you have a single IP address on the Internet which is shared among all machines on your LAN.

However to further complicate things - if you are using a smart host - such as your ISPs SMTP server - then your queues could be clear but the server is still being abused. However in that scenario it is likely that your server would not be blacklisted on public lists, but your ISP may have noticed and not be very happy with you. If messages are not being delivered to the smart host then phone your ISP and ask - or they may phone you. Often ISPs will block first and ask questions later.

Finding the Source - Compromised workstation

A quick and dirty method to find the compromised machine is to simply stop Exchange from sending any messages by freezing the outbound traffic, and then block port 25 on the firewall and wait. A compromised machine will quickly show on the logs when it cannot connect. You can then go and find the machine and deal with it.

Having up to date Antivirus is not enough. Once the BOT is on the machine, it is no longer your machine. The only way to ensure that it is clean is to wipe the machine. BOTs are very good at hanging around and they will update themselves regularly.

There is a complication on this as well - if you have been foolish enough to browse from the Exchange server then the server itself may have a BOT and be sending out messages. However those messages would still not show in the queues. If you don't browse from the Exchange server then that shouldn't be the cause of your problems.

Finding the Source - Large Number Of Messages in the Queues

If you have a large number of messages in the queues, then those will be coming from outside your network. That does not mean you are an open relay, there are other ways that the spammer can abuse your server.

The two most common are authenticated relaying and the NDR attack.
I have discussed these in more detail in my spam cleanup article on amset.info - http://www.amset.info/exchange/spam-cleanup.asp .

However in short, authenticated relay is where the spammer has attacked your SMTP port trying to break a password - usually the administrator account. Once broken, the account is used to relay email. Authenticated relaying is enabled by default.

An NDR attack is where messages are sent to your server to non-existent users on purpose. Either as a directory harvest attack (to see what users are valid) or to get your server to bounce the messages to the "sender". The sender is spoofed and is the actual target.
Exchange 2000 is unable to defend itself against these kinds of attack without third party support. Exchange 2003 and higher has features built in to deal with this kind of threat, however if you have Exchange 2003 on Windows 2000 then you should not use them as Windows 2000 is unable to defend itself against a directory harvest.

So what do you do?

When you first notice there is a problem, you need to verify whether it is the result of an attack or compromised machine, or the result of a configuration error or change. Do not presume one or the other.
Once you know which it is then you can look further.

If you are dealing with an ongoing problem then pull the plug on the internet connection. That will stop messages going out and if the spammer is abusing your server will stop the messages from piling up. This will give you some breathing space to clean up and see what is going on.

If your IP address has been blacklisted, then use your ISPs SMTP server to send email through.

Ideally you should have at least two IP addresses so that the Exchange server can have its own address. If a workstation is then abused it does not result in your email IP address getting blacklisted.

Remember, any SMTP server is a target for a spammer. They don't want to use their own resources, they want to use those that belong to someone else so that they can hide.

Exchange 2003, Exchange 2007, MS Exchange Server, Networking General Exchange 2003, Exchange 2007, MS Exchange Server, Networking General

I have written a number of new articles for our technical site amset.info and finished off some that have been in preparation for a while.
Plus many articles have had minor revisions, links updated etc.

Exchange Related Articles

SMTP Diagnostics
A quick guide on diagnosing mainly outbound email delivery problems. http://www.amset.info/exchange/smtp-diag.asp

Build a Gateway Server
How to build and configure an SMTP Gateway to sit in your DMZ, a cheap way of getting the "Edge" functionality of Exchange 2007. http://www.amset.info/exchange/gateway.asp

Where has the disk space gone?
Where does all the space go on an Exchange server? http://www.amset.info/exchange/diskspace.asp

Mailbox Account (E2003)
Setting up a special account for accessing mailboxes en-masse, for example with exmerge or to make a bulk change using set perm. http://www.amset.info/exchange/mailboxaccount.asp

Post Install Configuration Guide (E2003)
A quick run down of the things you should do to an Exchange Server once installation is complete. http://www.amset.info/exchange/post-install.asp

Non Exchange Updates

The web site isn't just about Microsoft Exchange. The three most popular articles on the site are not Exchange related at all!

Internet Explorer Section
Another new section. I have written some new things for Internet Explorer and moved around other content from elsewhere on the site and collected it together in its own section.
New content includes Custom Side bar creation and creating a search sidebar - which was removed from Internet Explorer 7. http://www.amset.info/ie/default.asp

Synchronising Windows Mobile over Bluetooth
The articles on this process to date have been for Windows Mobile 2002 but are still some of the most popular on the site. Those are still available, but now I have also written two new pages on how to pair and sync over Bluetooth with Windows Mobile 5.0 and 6. http://www.amset.info/windowsmobile/bluetooth.asp

Windows Mobile Internet Sharing
A brilliant new feature of Windows Mobile 6 is Internet Sharing. This allows you to use the Internet Connection of your PDA with your laptop. http://www.amset.info/windowsmobile/bluetooth2.asp
I used this while at the Microsoft community event earlier in June because Microsoft UK still don't have guest wifi access! If you have a T-Mobile web and walk tariff on your PDA you can get the best use of it with this feature.

Coming Soon
We have something new coming soon for Microsoft Exchange Server. Launch hopefully within the next couple of weeks… more information will be released when we feel ready to share…

amset.info, MS Exchange Server, Networking General, Windows Mobile MS Exchange Server, amset.info, Windows Mobile, Networking General

On my technical site amset.info I have an article on how to detect the operating system in a login script.
The method that I use is to dump the results of ver out to a text file, then find the version number in those results.
Here is a code snippet based on what is on that page, for detecting Windows XP. (http://www.amset.info/loginscripts/os-id.asp)

 ver >"%userprofile%"\ver.txt
 
 Rem now find the operating system and act accordingly
 
 findstr 5.2 "%userprofile%"\ver.txt
 if errorlevel 1 goto XP
 
 :notxp
 echo not XP
 
 goto end
 
 :xp
 echo XP
 
 goto end
 
 :end
 echo end

When Vista was released, I decided to update the page to include Vista as an example.
I therefore added the following line:

 findstr 6.0 "%userprofile%"\ver.txt
 if errorlevel 1 goto Vista

However this was based on theory, and wasn't something that I had time to test before I uploaded the new page.

Needing to use it for a client who has a couple of Vista machines and part of the login script wasn't required for Vista, I tried using my own code to skip that section.
If failed to work correctly and I couldn't understand why it wouldn't skip the section I wanted, but worked for older versions of Windows.

The answer I found was in the results of the ver:

XP: Microsoft Windows XP [Version 5.1.2600]
Vista: Microsoft Windows [Version 6.0.6000]

It appears that findstr command ignores the "." in the string. So it was looking for 60 and was finding it in the XP ver results.

The solution is to change the string to search for to 6000 which results in a positive detection.

Update March 2008: With the release of Vista Sp1 the detection fails because Microsoft changed the version string, again. The updated commands required are here: http://blog.sembee.co.uk/archive/2008/03/17/74.aspx

Networking General Networking General