SharePoint for Cisco Fanboys (darn WEBDAV) – Part 2

Here I am back again, illustrating some of the interesting possibilities that SharePoint offers for Cisco people.

To recap my last post, I showed you a little perl script I wrote to get an IOS router or switch to dump its current configuration to a TFTP server. I then used one of several freeware TFTP servers to show how you can have a TFTP server save the captured file into a version enabled document library.

I then hit a snag in relation to using a Windows Service to do this task. In this article we will delve into this issue in more detail. In addition, I ended up delving much deeper than I intended. So, like my branding series, this is going to turn into a multi-part series too, covering some application development, configuration, security and governance issues. How many parts it will end up being is anybody’s guess!

This is a technically oriented series of articles for the most part, so for you people who like the governance and finance stuff, you may not get too much out of this one. Although this article (part 2) focuses on my issues and observations with the Windows WEBDAV client, if you are one of these people who have ‘special’ feelings when you see those pretty blue Cisco boxes like the image above, then you may find some useful content here. 🙂

SharePoint developers and architects may also find this of interest.

Now I previously mentioned that I tried three TFTP servers in writing this article and had some problems. They were:

• WinAgents TFTP (Commercial)
• SolarWinds TFTP Server (Freeware – Registration required)
• TFTPD32 TFTP Server (Freeware)

And let’s not forget good old PUMPKIN, just to make one of my CCIE friends, who read the first post and suggested I use it as an alternative, happy (although he forgets that years ago I was the one who told him about Pumpkin in the first place 🙂 )

Let’s review their capabilities and cover the issues encountered with each. As we go, we will get to see the uglier side of WEBDAV.

WinAgents TFTP

I’ve used this product several times in the past. At the time it was pretty much the only product that would natively run as a Windows service. It is not free, but buying it won’t exactly break the bank. It has a nice GUI, good logging and the ability to set up virtual folders to different underlying locations. Below is the main configuration screen and the screen where multiple locations can be configured.

You would think that the above ability to virtualise folders would make this product an obvious choice for front-ending to SharePoint, because it could co-exist with native filesystem, DFS and 3rd party SMB based resources like those provided by samba.

You would be right, but the latest version is let down by one stupid design flaw. When you send a file to a WinAgents TFTP server that already exists, it will delete the original file and then copy the new file to the virtual folder. It may on the surface seem no different to simply overwriting a file – but there is a big difference in a SharePoint site.

All files in a SharePoint document library have a unique ID. It is a built-in column and can be made visible by modifying a document library view as shown below.

 

By deleting the file in SharePoint, that file is now put into the recycle bin. When you upload a file of the same name, SharePoint treats it as a new file and allocates it a new ID. Therefore, there is no version history at all. Each upload is deleting the previous version and uploading a new file.

This obviously blows away any potential to use WinAgents TFTP as a SharePoint integrated TFTP server :-(.

CleverWorkarounds Rating: They probably thought it was a good idea at the time.

Solarwinds

So instead, let’s now turn our attention to the SolarWinds TFTP product. This one is free and also very easy to use. Like the WinAgents product, it can be run as a service out of the box, but it is not as comprehensive as its commercial competitor in terms of logging, granular security filtering and folder virtualisation.

Unlike its commercial cousin, however, it does not delete files before uploading, and therefore plays nice with SharePoint version control. That, combined with natively running as a windows service, makes it the obvious contender to be the SharePoint TFTP server of choice.

The GUI is basic yet functional. There is a status screen and a configuration screen that allows you to set the TFTP Root directory as shown below.

 

In the screen-shot above, you will notice that the TFTP Server root directory is \\tidemo\tftp\backups. As I explained in the first post, this is the WEBDAV UNC equivalent of the SharePoint site http://tidemo/tftp and the document library called backups.

If you recall in the first post, we created a user account called ‘tftp service’. This account has been granted access to the http://tidemo/tftp/backups library. So, we need to set the credentials of the WinAgents TFTP service to run as that user. Therefore, when files are received by TFTP clients, the server will be able to write to the library. Below is my screen capture of my configured TFTP server.

 

There was one other task I also had to do to test this setup. SolarWinds is a little bit naughty in that it logs to its installation folder. (‘tsk ‘tsk will never get a designed for XP gold logo). Being good practitioners of IT security, the ‘tftp service’ account is a domain user with no system privileges, and only has READ access to this folder by default. Changing configuration parameters (such as the UNC TFTP root) also would not be saved, because the TFTP server would not be able to write to its own configuration file when running as the ‘tftp service’ account..

So the permissions of the SolarWinds installation folder has been modified so that the ‘tftp service’ account has WRITE access as shown below.

 

So I started the service fine, and ran a test! Wohoo we have our file!!

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

So I tried it again a few times and hit a snag after some successful retries…

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

[snip many successful reattempts]

C:\TFTP 192.168.134.129 put myfile.txt
Error on server : The process cannot access the file ‘\\tidemo\tftp\backups\myfile.txt’ because it is being used by another process.
Connect request failed

This was odd. Suddenly I was unable to copy a new version of the file to TFTP. I was running many repeat tests, so perhaps there was some sort of temporary file lock causing a problem? So I waited for a bit and then was able to transfer successfully again as shown below.

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

But it wasn’t long before I got another and more severe error.

C:\TFTP 192.168.134.129 put c:\myfile.txt
Error on server : The network path was not found.

Connect request failed

The TFTP server log showed this error and ominous stack trace…

2008-01-23 21:49:53,102 [6] WARN  TFTPServer.Service.TransmissionPut – Exception caught while trying to open file for reading.
System.IO.IOException: The network path was not found.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
   at TFTPServer.Service.TransmissionPut.Begin(RequestPacket firstPacket)

Network path not found? What the hell was going on here? It worked a minute ago!

Eventlogs came up blank, and I tried an IISRESET. Still no-go. Restarted the TFTP service and I was able to transfer again. However, it didn’t take long for the problem to re-appear.

I tried all of the suggestions on Mark Muller’s blog article with no success.

I found two sites of interest and one seemed close to this issue. The first was here, where a developer was having the identical problem, and a Microsoft employee suggested not to rely on WEBDAV “especially when using services”. The second one was a confidence building quote from Microsoft themselves. They made an admission in their WEBDAV Whitepaper regarding the Web Client service. “The Web Client Service in Windows XP and Windows Server 2003 does not function correctly if you stop it then start it again without restarting the computer. Although a bug has been opened on this problem, the changes required to fix it are too large for a hotfix or a service pack and have therefore been delayed until a future major release of Windows”

Are you freakin SERIOUS!?!

Anyway, I decided that before I go off on a Microsoft bashing rant, I’d better double check that this problem was with SolarWinds TFTP or the obviously rock solid and stable WEBDAV client.

CleverWorkAround Rating (SolarWinds TFTP) – Judgement reserved till later

TFTPD32 TFTP Server

TFTPD32 is more than just a TFTP server. It also provides DHCP, Syslog and SNTP services as part of the deal. Unlike the previous two TFTP servers, it does not run as a windows service out of the box, but it can be easily made to.

Cisco have also decided that this is their recommended TFTP server as well, not a bad endorsement, eh!

If we focus on the TFTP server functionality only, it is basically the same as SolarWinds without the windows service bit. So WinAgents still wins for overall ease of use and granularity but as discussed it was a waste of time with SharePoint.

Once again there is a main status screen, showing you current activity, as well as a configuration screen where you set the TFTP server root UNC path.

So given that we had all of the WEBDAV stability problems with SolarWinds, this TFTP server allows us to test two scenarios. Since it can be run as standalone, we can run it interactively as our ‘tftp service’ account and test it. Then, we can use a 3rd party tool to make it run as a Windows Service, and compare notes.

So first up, let’s run it interactively as rtftp service’ account. This is achieved by RIGHT clicking on the TFTPD32.EXE file and choosing RUN-AS from the menu options. When prompted, enter the credentials of the ‘tftp service’ account.

 

If you want absolute assurance that TFTPD32.EXE is being run by the ‘tftp user’ then look for the process in “task manager” and check the “User Name” column.

So, here we go!

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

[snip many successful reattempts]

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

Now occasionally I received the error below, but unlike when using SolarWinds, running as a windows service using ‘ttp service’ user credentials, it would always happen once and subsequent attempts would be fine.

C:\TFTP 192.168.134.129 put myfile.txt
Error on server : Access violation
Connect request failed

Just to prove that it was much more reliable, we now look at the version history in SharePoint for the file myfile.txt

CleverWorkArounds Rating: Not flawless, but reliable

So we have ascertained that running TFTPD32 works pretty well when run interactively as ‘tftp service’ . Now we have to run TFTPD32 as a service and compare 🙂

TFTPD32 as a windows service

There are many utilities out there to run a regular EXE file as a Windows Service. One of the most popular ones is SVRANY from the Windows 200x resource kit. However I used the freeware ServiceInstaller because it had a nice GUI 🙂

Using it is mind numbingly simple. Run the application and fill in the form as shown below and click the ‘Install’ button. Once installed, you can then change the service credentials to ‘tftp service’ the same way we did it for SolarWinds.

Start the service, and check in Task manager that TFTPD32.EXE is running. (When running as a service you will not see the status screen).

The moment of Truth!

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

[snip many successful reattempts]

C:\>TFTP 192.168.134.129 PUT myfile.txt

Transfer successful: 43552 bytes in 1 second, 43552 bytes/s

Like when running interactively, I still received the occasional  ‘Access Violation’ error but always recovered. Again to prove that I ran lots of TFTP commands, the version history is now up to 204 :-).

CleverWorkArounds Ratings (TFTPD32 as a service) – The best of the WEBDAV TFTP bunch

CleverWorkArounds Ratings (SolarWInds) – Looks like it might be part your fault after all!

CleverWorkArounds Ratings (WEBDAV) – It’s definitely your fault!

 

Conclusion

So after these tests, it seems that running TFTPD32 as a Windows Service is no less reliable than running it interactively. Perhaps then there is an issue with the way that SolarWinds use the windows networking API’s to write files. SolarWinds is a .NET application and TFTPD32 isn’t. Therefore, they may well be using different API’s under the hood.

I wasn’t satisfied with all of this though. Although we have achieved our goal of TFTP to a version controlled document library, the whole unreliable WEBDAV thing left me with a bad taste and I decided to go down a different path. What more could I do, you ask? How about write my own TFTP server? 🙂

The next 2 posts in this series will cover getting TFTP files into SharePoint via *non* WEBDAV methods. We will examine their reliability and examine a little of SharePoint web services and the SDK.

The fifth article will leave the issues of getting the files *into* SharePoint, and instead focus on what we can do with them once they are there! (Workflows, metadata and the like).

The final article (I suspect it will be the final anyway but i won’t know ’til I write the next two), will tie it all together in terms of governance. Thus, it will be a little similar to the branding series where the last article was largely non technical in focus and audience.

I hope you’ve enjoyed this little journey and didn’t find it too pointless 🙂