dbr's questions

Question: What is the best way to determine whether the limitations of SQL Server Express are the bottleneck in an environment? Are there some performance counters that would be a good indication for example? Would some of the information within SQL Server Activity monitor provide good evidence? The database size limit is an easy one to check, but the others are a little less clear-cut. Looking at system-wide perf counters doesn't seem to be the right approach if Express is restricted in terms of what resources it will utilise.

A related question - is it possible with SQL Server to easily trial Standard edition without having to reconfigure things drastically either before or after the trial? The ideal would be a way to "switch on" the capabilities of the full-fat edition on an existing instance, and then possibly roll back if needed afterwards. If that's not possible, then installing a separate instance and moving the database temporarily wouldn't be too bad.

Background: I have an environment in which the main application is a Windows-based line of business application backed by SQL Server Express. The application has performed poorly for a long time, but up until recently, the hardware, software and general environment were old and poorly maintained, meaning moving to a new environment with updated software and modern, more adequate hardware may well help. The application vendor believed upgrading from SQL Server Express 2008 to 2014 or above would help, but it wasn't practical at the time.

Having migrated to an entirely new environment with modern hardware, Windows Server 2016 and SQL Express 2016, the application is still performing poorly. We suspected this may happen if the bottleneck is in fact the limitations of SQL Server Express; however, I'm unsure of how to definitively determine that this is the case and it's not something else. The new environment has ample resources in terms of CPU, memory and disk, so I think it's unlikely, but I would prefer to have some solid proof.

If anything, it is slightly slower than before, perhaps due to the SQL database engine and application now running on separate VMs (albeit on the same virtual switch), whereas previously they were both running on the same physical box.

As anyone who has looked into it will know, full-fat SQL Server is not cheap, so the business case would need to be backed by solid evidence that this is what's needed and will definitely provide a boost.

I am in the process of implementing an MDM solution in preparation for rolling out a large number of Android devices. We use a number of apps that are installed from the Google Play store and not side-loaded. As I understand it, a phone must be configured with a Google account before one can install apps from the store. On the test devices I have, I've simply signed up for a couple of Google accounts and have manually added them to the phones. However, that's not exactly ideal when I come to to do a mass roll out.

So, my question is this: how would one typically manage Google accounts in a corporate scenario with MDM? I've been investigating bits such as Google Directory Sync and Android for Work, but am unsure whether I'm barking up the right tree.

Apologies if I've fallen foul of the X/Y problem - I may even be wrong in thinking a Google account is required at all.

If it matters:

• I'm using MobileIron Cloud, so not Google's own MDM product
• The devices are Samsung and so support SAFE, Android for Work, etc
• The organisation has a Windows domain
• The devices are corporate owned and not BYOD

We have several Surface Pro 3 devices deployed with BitLocker enabled in TPM + PIN mode. The devices have a TPM 2.0 chip and are running Windows 8.1 Pro.

We have an issue where users are occasionally presented with the "Too many incorrect PIN attempts" error when they enter the correct PIN. They must then enter the recovery key to be able to continue the boot process. They then need to enter the recovery key every time they boot the device until we manually reset the TPM lockout using tpm.msc, which is obviously inconvenient.

For some reason the TPM is entering the lockout state, but it doesn't seem to be because of repeated incorrect PIN attempts. The fact the lockout doesn't eventually time out if you leave the device running also suggests it's for some other reason other than reaching the maximum number of incorrect authentication attempts. I understand the TPM 2.0 spec states that this should be the case, unlike the TPM 1.2 spec which left the exact behaviour to the vendor.

Running Get-Tpm indicates that the TPM is definitely in a locked state, but doesn't provide any information about the cause.

Does anyone know if there is anything I could do to try and determine the root cause of the lock outs?

A question I recently asked regarding the use of enterprise 10k vs. 7.2k midline SAS disks led to some suggestions that the use of a mirrored pair of SSDs as a boot volume can make sense because:

• Prices for smaller, read-intensive SSDs suitable for boot volumes are not massively different from HDDs
• The increased I/O can be advantageous, particularly in situations such as reboots and patch installation where getting the server back up and running as quickly as possible is desirable

This led me to look into the available options a little more. I use HP kit, so my questions relate to that, but no doubt some of it is applicable across the board.

Firstly, a couple of people mentioned that HP make SSDs specifically designed for use a boot volume. Looking at the HPE SSDs data sheet, it mentions the Read Intensive SFF/LFF models as being ideally suited. Is this what people are referring to? I did see a couple of models specifically entitled "Enterprise Boot", but I'm still trying to work out whether they're an older line or not. It also mentions M.2 models, which is something I need to read into a little more.

Secondly, looking at the SSD options available for an HP DL380 Gen9 SFF chassis, I've notice that the sorts of capacities such as 80GB or 120GB that would be ideal for a boot volume are only available with a SATA interface.

As an example, a 120GB Read Intensive-3 SFF drive with a SATA interface has a list price of £195.00. When it comes to SAS, the cheapest option is a 480GB Read Intensive-3 SFF drive with a list price of £839.00. Drive capacities for SAS go as low as 200GB, but those are write-intensive or mixed-use options that are more expensive than the read-intensive 480GB drive.

As a comparison, the equivalent HDD - a 300GB 10k Enterprise SAS drive has a list price of £179.00 - very close to the 120GB SATA SSD mentioned above.

Is the lack of lower capacity/price SAS SSDs common, or is my example using a DL380 not representative of the norm? If it is, does that mean people are generally using SATA SSDs for their boot volume? Is that advisable? I've always followed the mantra of sticking to SAS because the SAS command set is supposedly more suited to a server environment, RAID, etc (I'm not expert, so admittedly I'm 'playing it safe' in the absence of knowledge of the specifics). Does using SSDs change that? Is my thinking flawed to begin with?

The HP SSDs datasheet does say a couple of things which are semi-helpful:

The SAS SSDs transfer data at full duplex (bidirectional) allowing greater I/O bandwidth to alleviate bottlenecks .... SATA SSDs are great in half-duplex (unidirectional) direct connect scenarios when lower price is a priority

... which helps explain why having a SAS interface will improve performance.

Additionally SAS uses SCSI commands for error recovery and error reporting, which have more functionality than the ATA command set used by Serial ATA (SATA).

It's difficult to when this would matter without specifics. It's something I've heard before and is one of many things I'd like to spend time understanding better.

I should say that I'm using the list prices just to allow relative comparison between products - I appreciate actual market prices would differ.

When specifying servers, like (I would assume) many engineers who aren't experts in storage, I'll generally play it safe (and perhaps be a slave to marketing) by standardising on a minimum of 10k SAS drives (and therefore are "enterprise"-grade with a 24x7 duty cycle, etc) for "system" data (usually OS and sometimes apps), and reserve the use of 7.2k mid/nearline drives for storage of non-system data where performance isn't a significant factor. This is all assuming 2.5" (SFF) disks, as 3.5" (LFF) disks are only really relevant for high-capacity, low IOPs requirements.

In situations where there isn't a massive amount of non-system data, I'll generally place it on the same disks/array as the system data, meaning the server only has 10k SAS drives (generally a "One Big RAID10" type of setup these days). Only if the size of the non-system data is significant do I usually consider putting it on a separate array of 7.2k mid/nearline disks to keep the cost/GB down.

This has lead me to wonder: in some situations, could those 10k disks in the RAID10 array have been replaced with 7.2k disks without any significant negative consequences? In other words, am I sometimes over-spec'ing (and keeping the hardware vendors happy) by sticking to a minimum of 10k "enterprise" grade disks, or is there a good reason to always stick to that as a minimum?

For example, take a server that acts as a hypervisor with a couple of VMs for a typical small company (say 50 users). The company has average I/O patterns with no special requirements. Typical 9-5, Mon-Fri office, with backups running for a couple of hours a night. The VMs could perhaps be a DC and a file/print/app server. The server has a RAID10 array with 6 disks to store all the data (system and non-system data). To my non-expert eye, it looks as though mid/nearline disks may do just fine. Taking HP disks as an example:

• Workload: Midline disks are rated for <40% workload. With the office only open for 9 hours a day and average I/O during that period unlikely to be anywhere near maximum, it seems unlikely workload would go over 40%. Even with a couple of hours of intense I/O at night for backups, my guess is it would still be below 40%
• Speed: Although the disks are only 7.2k, performance is improved by spreading it across six disks

So, my question: is it sensible to stick a minimum of 10k SAS drives, or are 7.2k midline/nearline disks actually more than adequate in many situations? If so, how do I gauge where the line is and avoid being a slave to ignorance by playing it safe?

My experience is mostly with HP servers, so the above may have a bit an HP slant to it, but I would assume the principles are fairly vendor independent.

In the past, servers I've put together have all had 8 or fewer disks, so I've not had to give the storage controller much thought - a standard controller like the P440ar (my experience is with HP) that supports up to 8 disks is sufficient.

The server I'm currently spec'ing up will likely have between 10 and 12 SFF disks, meaning the usual standard P440ar will not be sufficient. To support >8 disks, it seems I have a couple of options:

1. Stick with the P440 and add a SAS expander card
2. Switch the controller to something like a P840 that supports up to 16 disks without a SAS expander card

Therefore, I've been trying to understands the pros/cons of each approach.

I appreciate that you have no option but to use a SAS expander if you want to create a RAID array that spans more disks than the controller itself supports. Assuming that's not the case, what are the pros/cons/differences between:

1. Smaller controller + expander
2. Larger controller

(where 'smaller' is a controller that doesn't support the required number of drives without an expander, and 'larger' is a controller that does)

... and when/why would one choose one option over the other?

We have a number of laptop users for which deploying software updates reliably and promptly is an issue.

The circumstances are:

• The users rarely come into the office. As a result, their computers are rarely connected to the domain/corporate LAN during boot
• Users do not have local admin privileges
• Pre-logon VPN connection is available
• Updates are the typical core apps (Java, Adobe Reader, etc), plus some line of business apps. Mixture of everything from MSIs to self-extracting zips
• Currently use no third party deployment tools
• Fairly small deployment (less than fifty users currently) so don't have the budget or resources for very heavy-weight solutions
• Users regularly connect to the network post-boot (and usually post-logon) via a typical client VPN (happens to be RRAS/SSTP in this case, but probably not relevant)
• Computers in questions are domain-joined Windows 8.1 Pro machines. Servers are all Windows Server 2012 R2

Because of the lack of connectivity to the corporate network during boot, Group Policy software installation doesn't seem to be a viable option for deploying application updates (or new applications for that matter), but I'd be happy to receive advice that says otherwise.

DirectAccess would probably open up more options, but isn't an option for the foreseeable future.

So, my question is this: what solutions would people recommend for reliable and timely deployment of applications/application updates to mobile users who are only rarely connected to the corporate LAN during boot? I'm open to third party tools if they're within the reach of small business.

I have noticed this answer which suggests Intune might be worth investigation (SCCM would likely be too much). Any other suggestions greatly appreciated.

I'm currently exploring my options for running a client VPN server within Azure. I've examined the Point-to-Site VPN functionality, and it seems to be more of a method for administrators to dial in, rather than a fully-fledged client VPN solution.

One of the remaining options is to run a client VPN server within an Azure VM. Many of the client VPN options make use of IPsec in one way or another, which uses IP protocols other than TCP/UDP for operation (ESP/AH). As far as I can tell, Azure does not allow traffic other than TCP/UDP to your virtual machines. Endpoint-based ACLs only permit you to select TCP or UDP. I've just been investigating Network Security Groups (NSGs) in the hope they may offer a solution, but they also only offer 'TCP', 'UDP' or '*' as a protocol option within ACLs. This leads me to believe that it's not possible to run an IPsec server within Azure. Is this correct, or are there options available that I've not come across? Obviously there are options that only require TCP/UDP (Microsoft SSTP comes to mind), but specifically on the question of IPsec?

As a side-question, what other solutions have people settled on when it comes to providing a client VPN to resources hosted within Azure?

I'm currently in the process of planning any required changes to an RDS infrastructure to cater for an upcoming increase in the number of users due to company expansion.

Currently, the system only has a single RDS Session Host server. The upcoming expansion caused me to wonder what the factors are that influence when you would make the decision to switch to a model with multiple session hosts.

One particular question that I'm struggling with: if you have the ability to easily scale up the existing host rather than deploying another, does it usually make sense to do that and avoid switching to a multiple host model until absolutely necessary? Bearing in mind the added maintenance and complexity that having more than one session host brings, it seemed quite a pertinent question to which I'm not sure I have a solid answer to.

I'll set out my current thinking on the competing factors. I'd appreciate other people's thoughts on these and whether there are other factors that are also important.

Having multiple session hosts introduces a level of redundancy, particularly if you run them with enough headroom to pick up the slack in the event you experience downtime with one of the hosts. However, you must ensure all session hosts have the same configuration. This requires extra work and introduces the possibility of differences between the hosts developing over time. Although I've not done it myself yet, I can appreciate how these concerns can be mostly address by using things like automation, centralised management and configuration control, but the skill level required is higher, and you have to put the initial effort in to implement the tools and processes. You also have the added complexity of load balancing between the hosts (using a connection broker).

Scaling up a single host keeps the complexity down, which I'm a big fan of whenever possible/sensible. You only have a single host to maintain. On the face of it, that makes me think that it's preferable to scale up an existing host as much as possible until redundancy becomes a serious concern. I have a feeling it isn't quite that simple though. Can anyone else offer their thoughts/experience?

To put some constraints on this, my particular situation involves using Windows Server 2012 R2, with the session hosts virtualised using Hyper-V. In this particular scenario, licensing isn't a major concern.

I have a client with a very basic single server setup that includes a small SQL Server Express database.

I recently configured Symantec Backup Exec 2010 Quickstart edition for them. This is the free, feature-limited OEM version of Backup Exec that does not include the SQL Server Agent (or any application agent). However, it does support VSS via the Advanced Open File Option (AOFO). In this situation, I've always configured a scheduled task to dump the databases and back up the dumps so I can be sure I have a consistent backup.

However, after running an initial test job of the whole box with AOFO enabled, I noticed that it happily backed up the SQL data files, including the MDF/LDF files, and simply gave me a very softly worded "recommendation" that I might want to consider purchasing the SQL Server Agent as it had detected SQL Server data. This is surprised me on two fronts:

1. It was my understanding that Backup Exec automatically excludes MDF/LDF files from flat-file backups using the Active File Exclusion or 'AFE' feature unless you manually disabled this via a registry key. My understanding was that this was because it's always a bad idea to back them up directly. The fact they weren't excluded was therefore odd and perhaps intentional.
2. The lack of any serious warning stating that the SQL data may be inconsistent, unrestorable or whatever. Just a polite recommendation regarding the SQL Agent.

This led me to wonder, is it actually safe to back up the SQL Server data directly if you're using VSS (via AOFO)? After all, that would presumably mean the SQL Server VSS Writer is called to ensure the data files are app-consistent before the snapshot is taken. Backup Exec seems to have 'let' me do it, despite having recognised the SQL data as such.

I appreciate that using a dedicated SQL Agent provides a number of benefits, but purely on the question of taking a basic, consistent, restorable backup, is this safe?

There seems to be very little in terms of a definitive answer to the question, with some conflict. Obviously in the absence of one I'll be taking the tried and tested route, but it's got me thinking.

Here's some of what I've found so far:

• http://www.symantec.com/connect/forums/backup-exec-2010-r2-sql-agent
• SQL Server Backups using Volume Shadow Copy
• https://dba.stackexchange.com/questions/27885/is-it-safe-to-rely-on-a-shadow-volume-backup-of-the-mdf-and-ldf-files

Small Form Factor (SFF) / 2.5" disks seem to have become more popular than LFF disks now due to them being preferable over LFF disks in many scenarios (lower power consumption, higher density, etc). However, LFF disks still seem to feature in major vendor's offerings (take the recently released Gen9 series of HP servers as an example).

Looking at the pricing of the disks, in most of the lower (sub-500GB) capacities, there seems to be little price difference these days. That begs the question, why are they still popular enough for vendors to feel it's worth investing in supporting them in their latest products? Is it purely because the LFF form factor disks are available into higher capacities than SFF disks, or are there other reasons why they are still popular?

Underlying this is the fact I'm trying to understand what objective justification there is for spec'ing out a modern server with LFF cages/disks over SSF. What scenario/requirements might mean LFF would be the preferred choice? Would you only really do this if you needed large, multi-terabyte disks at a sensible cost, or are there other reasons?

Back in the pre-Windows Server 2012 days, the recommendation seemed to be to have at least one physical domain controller sat along-side your virtualised DCs.

One justification for this was because if your Hyper-V hosts were clustered, then they required a DC to be contactable during boot-up. This makes total sense to me.

However, I would often hear people say it is still important to have a physical DC even if you don't have a clustered set up (say for example in a simple setup with a single Hyper-V server running a couple of VMs, one of which is a DC). The justification for this seemed (and I could never quite be sure) that you would still have a problem in the sense that when the Hyper-V host first boots, there's no DC present on the network. Cached credentials mean you can still log on, but what about all those bits that happen during boot up that mean having a DC around is beneficial? Is this actually an issue? Are there actually any operations that might run only at boot up that will cause a problem? Any Group Policies for example? What I'm basically asking is, does the physical DC argument only really hold water when clustering is involved, or was (pre-2012) there a significant technical case for it without clustering? This article from Altaro (see "The “Chicken-and-Egg” Myth" section) suggests there is no need, but I'm still unsure.

Now to the second (and main) part of my question:

Windows Server 2012 introduced several features targeted at addressing the issues around virtualising domain controllers, including:

1. VM-Generation ID - This addressed the USN rollback issue that meant snapshotting (or more specifically, rolling back to a snapshot) was unsupported/a really bad idea
2. Cluster Bootstrapping - This addressed the "chicken and egg" issue surrounding Failover Clustering that I mentioned above. Failover Clustering no longer requires a DC to be present during boot-up.

So my second question is similar to the first, but this time for 2012+. Assuming both the vDC and the host are 2012+ and you take clustering out of the equation, are there any other issues like those mentioned above that mean I should still consider a physical DC? Should I still be considering having a physical DC along-side my single, non-clustered 2012/2012R2 Hyper-V host that has a single virtualised DC on it? I hear some people suggest putting AD on the Hyper-V host, but I don't like that idea for various reasons (WB cache being disabled for a start).

As a side-note, my question implicitly assumes that it makes sense to have your Hyper-V host joined to the domain to improve manageability. Does this assertion stand up to scrutiny?

UPDATE:

After reading some answers, it occurred to me that I could phrase things slightly differently to get to the heart of what I'm asking:

Even with the improvements in 2012 and later, the fact still remains that without any physical DCs or virtual DCs on another host, the host still boots when there's no DC available. Is this actually an issue? In a sense, I suppose it's the same (or very similar) question if you take virtualisation out of the picture completely. If you start member servers before any DCs regularly, is that a problem?

I am currently planning a move of an Active Directory Certificate Services CA from a soon to be decommissioned Server 2003 R2 Standard box to an existing Windows 2008 R1 Enterprise box.

This is not something I have done before, so I've been looking through relevant documentation to get an idea of what's required, before testing the process in a lab. The most reliable and complete source of information seems to be Microsoft's Active Directory Certificate Services Migration Guide. However, it only covers scenarios involving a destination server running the R2 release of Windows Server 2008, and not "R1".

Can anyone offer any advice on whether the guide can still be followed as-is or whether the approach needs to be modified slightly? Does anyone know the reasoning behind only covering the R2 release as a destination server? Is it purely because Microsoft would expect users to be running R2? From what I've read so far, the guide is silent with regards to the omission.

In the past, when creating AD domains, I've used the common convention of using a sub-domain of the company's publicly registered domain name, e.g "corp.mycompany.com" or "int.mycompany.com". I've always accepted the default NetBIOS name when running DCPromo, for fear that creating a NetBIOS name that differs from the sub-domain may cause complications.

I've recently been doing a bit of research on the consequences of providing an alternate NetBIOS name. The main reasons behind this are:

• The NetBIOS name isn't particularly descriptive or unique to the company
• Apparently generic NetBIOS names such as "CORP" or "INT" can cause issues when merging IT systems (although I've not had experience with this myself)
• Providing something "before the slash" that means more to users (less important)

In looking at the possible downsides, the only one I can come up with is the disjointed namespace issue when configuring Exchange.

Can anybody with more experience than I elaborate on my findings at all?

Many thanks

This question is a follow-on from Dedicated NIC or dedicated port for iSCSI?

Excluding the hardware iSCSI initiator point that was made in the accepted answer to the above question, it seems that using separate port(s) on a multi-port NIC for iSCSI is pretty much going to meet the recommendation of using "seperate NICs" for iSCSI traffic.

I'm in the process of planning a small iSCSI installation that connects two cluster nodes to a storage array using redundant paths/switches via MPIO. As a result, each node has four physical network connections to the iSCSI switches.

Each machine has two quad-port NICs. Four ports are required for non-iSCSI traffic, and four for the aforementioned iSCSI traffic, meaning all eight ports will be in-use.

My question is this - If you have the luxury of multiple physical NICs in the box, should you split your iSCSI connections across the two NICs to cope with a NIC failure (in my case 2 ports each), or should you stick to keeping all iSCSI traffic on the single NIC? My hunch would be to separate the traffic, but I'd like to get the thoughts of those with more real-world experience of iSCSI than I. Am I going to hit some sort of unexpected complication doing it this way?

Although I've asked the question in the context of my particular example, I've tried to ask a general question that will hopefully be applicable to other similar configurations.

Any help greatly appreciated.

We run a small business network with a few Windows servers and Backup Exec + an LTO4 tape library to back them all up. We use a yearly, monthly, weekly rota, with tapes going off-site. I should also mention that we use LTO barcodes.

My question is really this - What paperwork/spreadsheets/databases/etc do you use around a backup rota to achieve goals such as the following:

a) Ensure there is a written record of accountability showing that engineers have checked backup logs to ensure jobs are completing successfully, the tape is in good condition, etc (aside from anything else, this seems to be a good way to encourage the process to be followed if people must sign their name to say they've done it).

b) Ability to track where all tapes are currently stored (Backup Exec helps with this, but a separate record seems sensible). Would also be good if this record was somehow stored off-site so that it is accessible in the event of a disaster such as an office fire.

c) In a disaster recovery situation, there isn't just tapes stored off-site, but a written record explaining exactly what job the tapes correspond to, with a record showing the job completed successfully, etc.

d) Anything else that's important

In short, an audit trail. An audit trail that is designed is such a way that it is resilient to disaster situations such as office fires.

Do people tend to roll their own solution, or are there off-the-shelf solutions? Do you tend to keep it all paper based, or do you have some electronic method? Do you keep any paperwork with the off-site tapes?

I should say that we already have a basic system in place, but I'm interested to see what makes up a good audit trail system, in the hope I can improve ours.

Many thanks!

I'm rewiring a rack, and would like to have the cabling cut to length to make things as tidy as possible. The suppliers of Cat5e/Cat6 cable I've found only really supply bulk cable in multiples of 100m. I don't need anywhere near that sort of quantity, and buying that much of each colour required would be unnecessarily expensive. As yet, I haven't found many suppliers that would supply bulk cable in smaller lengths for what I need.

My question is this - If I want to be able to do the above, should I be:

a) Continuing to look for a supplier that will supply shorter lengths of bulk cable more suited to my requirements (perhaps cut to order?). Is this common?

b) Buying individual pre-made patch cables, cutting them to length and crimping a new connector?

c) Give up on the idea and just use the most suitable length of pre-made patch cable?

d) Some other option that I haven't considered?

I should also mention that I'm aware of the labour cost argument regarding making your own cables vs. buying pre-made ones. I certainly wouldn't be doing it for every cable I use, but for cabling up a rack, I think the extra tidy-ness acheived is worth while.

Any advice greatly appreciated.

I'm currently in the process of researching options for a two-factor authentication system for our company. I'm currently investigating the pros/cons of certificate-based tokens vs. one-time-password (OTP) based tokens (RSA SecurID being the most common). Initially it'll just secure our VPN, but may include other services at a later stage.

As I understand it so far, cert-based tokens seem to have many advantages over OTP tokens. They support other uses such as pre-boot authentication, full disk encryption, e-mail signing, etc. The cert-based tokens are configurable on-site and don't require someone like RSA to manufacture them to order. I appreciate that they require a PKI, which not everyone is willing to setup or maintain, whereas OTP tokens don't.

Despite the above suggesting that certificate based tokens seem like the better option these days, I get the impression - perhaps wrongly - that OTP tokens are still much more popular. Is it simply the case that they're cheaper and/or simpler to implement than cert-based tokens? Am I missing something? Is my assessment of the pros/cons largely correct? Why would you select one over the other and in what situation?

When spec'ing and configuring a machine that will utilise shared iSCSI storage, I've read a lot of documentation which suggests a dedicated network adapter should be used for iSCSI communication. That makes a lot of sense and I have no problem with it. The question I do have, is this - should that suggestion be taken to mean that a separate physical NIC should be used, or will a dedicated port/ports on a dual/quad port NIC be just as good? My suspicion is that simply using dedicated port(s) on a shared NIC would be just as good.

Any input greatly appreciated.

I have a leased line which is capped @ 10mbit/sec up & down. Border device is a Draytek Vigor 3300V+. I have a couple of Dell servers running Windows 2003 behind the Draytek. My issue is that the upstream speed from the servers maxes out at about 7-8mbps when accessing them from another location. As a test, I installed Ubuntu on a laptop & stuck it along side the two servers. I ran the same tests from that machine, and the upstream was a steady 10mbps as you'd expect. I've run both iperf and http tests, with the same results. If I access the machines locally, it's nice and fast as you'd expect on a LAN. They just seem to be unable to effectively make use of the 10mbps bandwidth available to them on the leased line. I've tried all sorts of things in an attempt to diagnose what could be the issue affecting the Windows machines, but without any luck. Here's some of the things I've tried...

• Updating network drivers
• Disabling/enabling various advanced settings on the NICs
• Running Wireshark traces and seeing if I can spot any obvious problems
• Latest firmware on the Draytek
• Ruling out any other network equipment (switches, cables)

A few more details that might be relevant:

• Both servers are Dell PowerEdge 2800 machines
• Both run Windows 2003 Server (SBS Edition & Standard Edition) R1
• Both machines have Intel Pro 1000 MT Dual Port adapters

My networking knowledge really isn't up to scratch to diagnose this problem easily. I'm busy brushing up on my low level network in the hope of being able to draw more from the Wireshark traces that I have. Any thoughts of anything else I could try would be very much appreciated.