Maarten Van Driessen


Powershell/Windows

Remove Logs

Posted by Maarten Van Driessen on

A couple of our web servers were running into some issues with disk space. Turns out the logs weren’t being cleaned up properly.
In order to remediate this, I wrote a function that can be reused anywhere.

The function accepts 3 parameters:

  • FilePath: The directory where you want to remove the logs from
  • CutOff; Specifies the age (in days) that a file must have before being deleted.
  • LogPath; This parameter specifies the directory where you want the CSV log file. If this is left open, no CSV will be saved.

Example

As an example, I’m going to remove all files, older than 30 days, from the folder “C:\temp\W3SVC2030036971\W3SVC2030036971\”. I want a CSV log to be written in the “C:\temp” folder.

remove-logs1

A view from the Powershell window

As you can see, you always get feedback in your window, even if you don’t specify a log path.

The CSV looks something like this:

remove-logs2

Code

You can find the script code below. This is provided as-is. You can find the most recent version of the code on GitHub.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
VMware

Install VIB on VMware ESXi

Posted by Maarten Van Driessen on

Today I got my shiny new host for the homelab. After installing ESXi, I noticed the 10 Gbit NICs weren’t being detected. After looking around a bit I found the drivers in the form of a VIB.

Start by uploading the VIB to a datastore that is accessible to the host. Turn on the SSH service in the security section and fire up a session.

Once connected run

If everything goes well you should get an output like this

Once all is done, reboot the host and you’ll see the installed device pop up, in my case the 10 Gbit NICs

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Network

How to upgrade an IRF stack – incompatible firmware

Posted by Maarten Van Driessen on

When upgrading HP Comware switches that are part of an IRF stack, you want to use In Service Software Upgrade (ISSU). This allows you to do a rolling upgrade of the firmware while limiting the impact to just 1 switch in the stack.
ISSU will reboot 1 switch in the stack, wait for it to come back up and then moves on to the next switch.

Types of ISSU

There are 3 types of ISSU:

  • Compatible: This means 2 different software versions can co-exist in the same IRF stack. This is usually for smaller releases, in the same major release
  • Incompatible: Typically you will see this when moving between major releases. Only 1 version can exist in the IRF stack
  • Unknown

Upgrading incompatible firmware

Checking configuration

Before starting the upgrade, you have to check your configuration. Doing an incompatible upgrade means you will create a “split-brain” situation since only 1 version can exist in the same IRF stack.

To prevent this, you have to make sure MAD is configured. You can check this by running the command

This will give you an output like this, in this example MAD BFD is used.

Also, make sure your IRF stack is configured correctly and as desired by running the command

Uploading the image

After you verified that everything is configured correctly, it’s time to upload the image. You can do this using any number of methods. Once the image is uploaded to the master node, you need to copy it to all slave nodes. Increment the slot number if you have more than 2 switches in the stack.

copy new5500.bin slot2#flash:

Once the image is uploaded, you can check the compatibility

Starting the upgrade

It’s time to actually start upgrading. When the command is issued, the slave node will be loaded with the new firmware. The node will then reboot but will not join the IRF stack (remember, only one version can exist), this will create a split-brain situation that will be resolved by MAD. MAD leaves the IRF ports active but will shut down all outgoing interfaces. You might wonder why the IRF interfaces aren’t shut down, this is done to allow you to perform the switchover and continue the upgrade.

Once the slave node has rebooted, you can perform the switchover. This will reboot the current master node and perform the upgrade to the new firmware version. The command will also enable all external interfaces on the node that’s already been upgraded, the new master.

After the node has rebooted, the IRF stack will be fully operational.

If you want the IRF master to be the same as before the upgrade, you can reboot the current master.

 

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Windows

When DFS Replication goes wrong…And how to fix it

Posted by Maarten Van Driessen on
A while back a client of ours had some issues with DFS replication between 2 nodes. One of the members reported a backlog of over 1 million files!
Upon further investigation, I found the DFS database on that node got corrupted which caused it start the initial sync again.

We let the process run it’s course over a couple of days but noticed the progress was incredibly slow. We were averaging about 3000 files / hour. After some quick math, it’d take about 16 days before the sync completed. And that’s not taking into account anyone working on the file servers.

That is when I stumbled upon this very detailed blog post by Ned Pyle. There he explains in great detail how the process can go faster, using a DFS database clone export and import.

DFS state of affairs

One thing to pay attention to, you can’t import a DFS database on a node that already has a pre-existing database. In order to make this strategy work, we had to make sure all traces of the existing DFS database were gone.

This isn’t as simple as just removing the member and adding it again. When you delete a member from a replication group, that member isn’t actually deleted from the database. The member is marked with a 30-day tombstone flag. If you change any files on that member and then re-add it, the tombstone flag is removed and the files on that member are used and replicated to the other members. You can imagine this can get really ugly if you decide to delete files on that “removed member”. The key takeaway here is to make sure you have a backup before you make any changes!

We decided the easiest and safest way to go ahead was to delete all replication groups and recreate them. Simply removing the replication group isn’t enough. You also have to make sure there are no remnants of the database in the “System Volume Information” folder. The easiest way to do this is by running these commands

This will move the contents of the folder to a DFSR_backup folder on the same volume. Note: make sure you delete the replication groups before running these commands. If you don’t do this, DFS will just recreate the database on that member.

Checking the nodes are in sync

First, we had to make sure that any files that had changed on the remote node were copied to the node on the main site.
Sounds like a job for robocopy! I found out that the database got corrupted on the 12th of December, so we only had to check the files modified after that date.
The command looks like this


This command will compare all files newer than the 11th of December and copy them over. The /XF parameter excludes the thumbs.db file from being copied in order to speed up the process. Our client works with a lot of images so there are a lot of thumbs.db files.

Moving on

To finish setting up your DFS-R, you can follow the steps outlined in the blog post I linked at the top of this page.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Network

Setting up IPSec VPN between Fortigate and Axsguard

Posted by Maarten Van Driessen on

If you’ve ever had the “pleasure” of building an IPSec tunnel between 2 endpoints from different vendors, you’ll know how smooth that usually goes. Today I was building a tunnel between a Fortigate 70D and an Axsguard Gatekeeper, as you can guess, things didn’t go as planned.

Fortigate

Let’s start by creating the tunnel on the Fortigate. Create a new tunnel and select the Custom VPN Tunnel template.

FG-tunnel1

 

Next, fill in all the phase 1 settings. In this example, I’m using 3DES and SHA1. While 3DES is still considered as secure, I would recommend against using it in production, mainly because of the speed. If you want to use the public IP address as the local ID, leave the field empty. Fortigate will automatically send its public IP as the local ID. Keep this in mind when you’re behind a NAT device.

FG-phase1

In the phase 2 settings, you can specify what addresses should be configured on the tunnel. You can choose between a subnet, IP range or a single IP address.

FG-phase2

 

You will still need to configure a route and firewall rules for VPN traffic.

Axsguard

The same principles apply to the configuration of the Axsguard.  One thing to pay attention to is the key lifetime, Fortinet uses seconds to express the lifetime on its devices. Axsguard, on the other hand, uses minutes for the lifetime.

Let’s go ahead and create a new tunnel on the Axsguard. Fill in the local parameters. If you can’t find the settings that correspond to the settings on the Fortigate, you can add them in the IPSec -IKE, and IPSec – ESP menus. Make sure to set the settings exactly the same as on the Fortigate.

Axsguard local parameters

 

Same goes for the remote parameters.

Axsguard remote parameters

 

The Axsguard will automatically create the required firewall rules to allow traffic to pass through the tunnel.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Network

Using VLANs on Fortigate 30D

Posted by Maarten Van Driessen on

While setting up a new Fortigate 30D for a client, I wanted to add a new VLAN for the guest Wi-Fi network. Usually, you just go into NetworkInterfaces and add a new Interface there.

On the 30D however, this option wasn’t there. After changing the device from switch mode to interface mode and back, I figured you can’t do it in the GUI. The only way to do it on a 30D is by using the CLI.

To add a new VLAN, go to the dashboard, open up the CLI and enter these commands:

After running these commands, you’ll also see the VLAN show up in the Network – Interfaces page.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin
Office

Word 2013 High CPU usage

Posted by Maarten Van Driessen on

Late last week I had a client call me about Word acting slow. After a quick checkup, I noticed that Word was using 25 – 40% CPU. I hadn’t received any other reports so I assumed it was a one-off and recreated the document. This sorted the issue for that particular computer.

Today I got the same report from a dozen more people. I started digging around in the documents that were having issues and noticed a drop in CPU usage when removing the header and footer. More specifically, removing images or objects in the header and footer.

Since I didn’t have the issue on a freshly installed computer, I began suspecting updates were the cause. Sure enough, after removing KB3114717 everything went back to normal.

Microsoft has pulled the update already and advises people to uninstall it.

Facebooktwittergoogle_plusredditlinkedinFacebooktwittergoogle_plusredditlinkedin