Kill hung IIS windows FTP sessions

During some integration development some FTP sessions got created with keep alive on them, but how to remove them?

List active FTP sessions in IIS

Sounds simple, but was not so easy. The live sessions are listed in IIS under the ftp site in question. Select the site in IIS and then under FTP section, there should be a FTP Current Sessions. Double click will open a window with the current sessions in it.


It is possible to disconnect the sessions by right clicking them, you can restart the whole ftp site and yet the sessions will keep bouncing back, if they were set to keep alive when created.

How do we kill an active session?

To kill them Google comes up with lots of solutions for Linux and recommends the download of many different tools to do the job. Personally I don’t like installing tools on my production server, so I dug deeper, there had to be a way to do this using commands, I found there is!

List the connections using netstat

To view the sessions, open command prompt and issue the command:


netstat –ao

This will list all the sessions, look for the sessions that are of concern, the originator IP address will give them away. At the far right will be the process id for those sessions (PID). Note this for the sessions that need to go.

In our example the process on my server was PID 1672.

Kill the session using taskkill

Now we need to kill the FTP PID in windows. Use this command to do that:


taskkill /PID 1672 /F /T

Where the command switches are F= Force and T=Terminate and 1672 is the process ID on your server that you obtained earlier from the netstat command.

Check back in the FTP sessions window and the sessions should be gone forever.

I hope this was useful to you, do comment if it was!

Enterprise Software Podcast

If you are involved in ERP software, no matter what vendor, then the Enterprise Software Podcast is a good aggregator of news and views on the ERP software market. Informative and usually quite light-hearted.The content is product agnostic and is provides an easy way to keep in touch with the gossip, including who is moving to what company.

Go check out the old episodes and subscribe to the new ones here: Enterprise Software Podcast

Enterprise Software Podcast microphone logo

Little did I expect when I started listening, what was some time ago now, that one day I would get to talk on the podcast. While at GPUG Summit I was given the opportunity when I was asked for an interview. Luckily it stayed  very shallow and so I didn’t get to rant on any contumacious issues like Dynamics 365 or other subjects, in our market space, keeps me safe from putting my foot in it!

If you are interested it is going to be episode fifty two. I’ve listened to the rushes already, I understand that expected publication is 19th Oct 2016.

Visual Studio menu font size stuck after presenter mode

Presenter mode in visual studio (accessed via the quick launch at top right), allows VS to switch into a larger font layout, ideal for LCD projector presentations.

Presenter Mode Visual Studio

Whilst I had this mode on I had a crash in visual studio and had messed with other settings One of these meant that when I switched presenter mode off, it was no longer taking the font size of the Visual Studio menus back down to normal. Although for a couple of days I lived with the large fonts, I finally looked at it today. Get yourself to the following Visual Studio

Tools>>Options>>Environment>>Fonts and Colors *US spelling

or type fonts into the quick launch, quick launch is really helpful for these kind of things…

Quick Launch - To Find Fonts and Colors

Now in the options window use the drop down to to select Environment, followed by clicking the “Use Defaults” button. When the overall window is “OKed”, then Visual Studio will return to normal, this same procedure can also be used to correct any of the other options in the drop down box.

Font Settings set Environment & click Use Defaults

After doing this, presenter mode on/off works again as expected.

More about presenter mode

.NET Power Tip 6: Presenting in Visual Studio (Presentation Mode & ToolBox Snippets)

6 Quick Tips for Presenting Code in Visual Studio

Bug with Address Name in SOP Entry of Dynamics GP 2015R2

We found on this issue, setting the ship to address from the main SOP entry window in our production Dynamics GP does not pull the correct field from the Ship To Address Name of the address book record into the order Ship To Field. Instead the company name of the account is used. It does work correctly when the selection is made on the Sales Debtor Detail window.

We have mods running on this server and I don’t currently have a clean VM to test on, so wouldn’t mind some verification from anyone else with this issue.

To reproduce the issue

Set an Address name in a debtor customer address, in our example I have set the company address name to be “Fake Address Name”, as shown below:

Fake Address Name set as Address Name for Ship To

Now create a sales order for that customer, then select the above address, do so by using the picker on the main window of SOP entry, for Ship To Address, as highlighted below.

Use Ship To Address Picker

Now check the ship to address that has been set. You will see that the name from the debtor has been used and not the Ship To Address Name from the address record.

Address Name set to account Name

Repeat the previous procedure, just this time use the address picker in the Sales Debtor Detail Entry window to select the ship to address. Now go check the ship to address, see how it has taken the correct ship to address name.

Address Name correctly set to ship to name

Although the users have be instructed to use the latter method to select an address, they slip back into using the former method, that then causes customer service issues with deliveries not being made as the shipping to company name is incorrect on the order.


UPDATE: 2016-10-19

I had a few moments today so I tested this today on my GP2016, a clean VM and found the issue was not there, so now even more curious as to if this is a bug with our 2015R2 instance or something that has been fixed in 2016. Rob Klaproth kindly pointed out my lack of documentation on the issues, version of GP especially, these are now included in the post! I don’t think I have reported this to MS as a bug, but with the GP2016 revelation, I don’t feel the need now.