Lukas Beeler's IT Blog

You can easily copy configurations from one IAS server to another, Microsoft documents this here.

Basically, you can use netsh aaaa dump > file.txt to dump the config to a file, and import it using netsh file < file.txt to import it.

But here comes the interesting part – after importing the configuration, my WLAN client failed to connect. But why? Simple, you will need to enter the PEAP-Dialog, and choose a certificate. After that, everything will work fine.

Electronic Service Agent supports VPN connections with NAT pass through since i5/OS V5R4 (there was a “beta”-version of this in later i5/OS V5R3 CUM-Packages, earlier versions, like OS/400 V5R2 didn’t support VPN connections for ESA). Ensuring that your System i (or iSeries, or AS/400) can communicate with IBM is necessary if you have a HW-Maintenance or SW-Maintenance contract.

Now, if you want to allow this traffic through a firewall, you will see that IBM doesn’t exactly document this too much.

Generally, you will need to allow these things from your System i:

• Outgoing ICMP echo request (PING)
• Outgoing UDP traffic to Ports 500 and 4500
• Outgoing ESP packets (Protocol 50)
• Accept incoming packets from established connections

If that’s to broad for you, you can restrict the above traffic to these two IP adresses:

• Boulder: 207.25.252.196
• Rochester: 129.42.160.16

Note that these IP Adresses may change in the future.

I’ve been asked many times why some applications are slow over a VPN connection.

In order to understand why this is the case, we must first understand what type of slow is normal, and what isn’t.

The most popular problem with VPN connections are MTU issues. Try a ping -l 1500 internal-ip. If that doesn’t work, you have an MTU issue.

The next step is to test the raw speed – copying a file with FTP or SCP to and from a server. Is the speed okay? If the speed is according to the lines used, your problem probably isn’t with the VPN connection.

The main problem with VPN connections is latency. The average latency for a roundtrip from ADSL to ADSL here in Switzerland is about 80ms. This is a lot of time, especially if you’re taking multiple round trips. If we look at other connectivity methods like UMTS (with about 500ms Latency), it gets a lot worse. 10 Roundtrips für ADSL are a second, but 10 Roundtrips for UMTS are 5 seconds.

You can use Wireshark to look at the traffic on the interface in order to see if the application that is slow uses multiple round trips to achieve it’s goal.

There are several well known applications that have problem with using multiple roundtrips:

The most popular one is SMB – it uses 5 – 10 Roundtrips for a directory list under certain circumstances. This means 0.5 – 1 second wasted on network latency (and this doesn’t even include the transmission time). The solution for this problem varies – if you need access from a site, use DFS-R and a server local to that site, if you want road warriors to have faster access, use Sharepoint.

Another thing causing many problems are ERP applications built onto the “Fat Client” design principle (Business Logic in Client), which queries the database directly – this ensures many, many roundtrips for every bit of information displayed. (Note that DIAS-iS doesn’t have this problem because it’s a Thin Client application, with the Business Logic in the server). Another remedy is an ERP application which can have servers in multiple sites, but this is probably not SMB software anymore.

There’s not really a solution for this, because it means switching ERP applications, or getting your software provider to start supporting high latency links.. A bit drastic for latency problems.

An interesting application regarding this is Outlook – Outlook is a hybrid. With Cached Exchange mode enabled, it behaves like a Thin Client, because it has a local replica of the database. So, the solution for Outlook is to always use Cached Exchange mode – a good idea anyway because it reduces load on the Exchange server.

When Windows Server 2003 R2 came out, many people thought there was nothing spectacularly new in it. But that’s not true.

While many of the new R2 features were meant for enterprise customers, there’s an important feature that can be used by anyone, as long as you’re not using the SBS version of Windows Server.

DFS consists of two seperate technologies, that can be used independently – the first one can be used no matter how small your business is:

DFS Namespaces

DFS Namespaces make it easy to provide a fault tolerant, single namespace for all your shares. With the time, clients probably have more and more shares mapped to network drives, which is both a hard to manage, and difficult to understand for the end users.

With DFS, you can show all your shares, no matter if they map to a NAS device, a Windows Box, an i5/OS instance running Netserver in a single, unified tree.

Note that this feature does not require anything except a Server running R2 and Active Directory. No additional licenses, no multiple domain controllers, etc. needed.

If you look at the picture to the right, you can see that that we have a unified structure, linking multiple shares into a single tree. You do not need to use replication or anything else.

Please note that you can still map the DFS root (here: \\int.dataline.ch\Public\) to a drive letter, in case you prefer that. The official stance is that you should use the UNC path everywhere, though.

Using a domain hosted DFS root has another big advantage – if you move servers, the links on your users won’t change. For example, if you offload all the Multimedia content from the server, and you move it to an Active Directory integrated NAS Box (like Snap Server), you just have to change the link in the DFS root – the users won’t even notice that it has moved to another server.

A domain hosted DFS root, hosted on multiple domain controllers gives you a fault tolerant redirection structure. Together with DFS-Replication, this gives you application redundancy (which is cool).

As you can see, there are several advantages with DFS Namespaces alone, that might make it worth the time it takes to implement DFS, no matter how small your Business is. Even if you have only one server, DFS can help you get a simpler directory structure for your users, and it can also allow you to make managment and moving of data easier. NAS boxes are becoming more and more popular in SMBs, because they offer very cheap storage.

DFS Replication

DFS Replication is a true multi master file replication implementation. DFS-R can be used over WAN and over LAN links – while the LAN variant is usually used to provide fault tolerance (which isn’t always implemented in a SMB), the WAN variant comes into play as soon as you have branch offices.

The DFS-R FAQ answers many questions related to DFS replication.

DFS over WAN links uses a technology called RDC – if you are familiar with Linux, you will soon notice that RDC is very similar to RSYNC, except that it’s a whole lot better. Why?

Cross-file RDC allows DFS replication to use RDC even when a file with the same name does not exist at the client end (provided either the client or server is running Windows Server 2003 R2, Enterprise Edition). Cross-file RDC uses a heuristic to determine files that are similar to the file that needs to be replicated, and uses blocks of the similar files that are identical to the replicating file to minimize the amount of data transferred over the WAN. Cross-file RDC can use blocks of up to five similar files in this process.

This is a very, very cool feature, that i’ve never seen anywhere else before.

You probably won’t need DFS-R if you only have a single office, and are not using application redundancy. But if you have branch offices, you can use DFS-R to have all the data in all your offices available. This makes it much more convenient to work, because the data will always be available from a local fileserver. Please note that you can’t really use direct SMB over high latency WAN links – SMB makes too many roundtrips, which will make everything feel very slow.

Conclusions

DFS Namespaces and DFS Replication can be used to provide HA fileshares – to provide a unified naming structure – to replicate content to and from branch offices while saving bandwidth. This is a whole lot of things that you get when you buy Windows Server 2003 R2.

Sadly, not many SMB admins know about DFS, or use DFS. But everyone should. There’s no reason not to use DFS.

Microsoft offers a nice Demonstration of the DFS technology – something you can even show your boss.

I’ve seen many people losing mail when changing MX records, for example when you switch from POP3 Retrieval to direct SMTP retrieval.

It’s rather simple to change MX records correctly, though there are some administrative hassles involves when you don’t have your own DNS servers. But the procedure can still be used, just ignore all the things about POP3.

If you control both mail exchangers, the whole thing is extremely easy

• Change your TTL to a small value. 5 Minutes is a good start. Note that you can change either the TTL of the MX record itself, if you change the Name, or the TTL of the A records the MX records points to, if you’re changing the IP address, and the MX keeps the same name
• Wait till your old TTL has expired. Note that with a default TTL of 86400, this means you will have to wait a day.
• Make sure the new MX is running, then change the MX record (or the A IP address). If you’re switching from MX to MX, now is the time to add an SMTP route
• Wait 5 Minutes, then retrieve your mails from POP3, this step ensures that no mail is lost for sure
• Change your TTL back to a sane value. If you’re a low traffic site like a SMB business, i recommend a TTL of 1 hour, 3600s. This makes it easier for future changes.