Script to automatically import documents from a network share on a regular schedule

Question

I am new to SharePoint development.

I am trying automate the task of:

• Uploading documents from a network share to a SharePoint document library.
• The related metadata for each of the files also need to be brought into the SharePoint columns. (will taken from a single CSV file in the same location with filenames mapped in it)
• This process needs to automatically run on a predefined schedule (eg: daily/once an hour etc)

I want to know:

• What is the best way to achieve this? (PowerShell script running on Windows task scheduler, creating a service etc.)
• Starting point for coding or any code already available since it looks like this might be a very common requirement.

I am using Microsoft SharePoint Server 2010 (14.0.4763.1000)

Answer 1

I generally perform this tasks by writing either a console application or (more and more) write a PowerShell script. These are then run by a scheduled task (bat-file or the script directly).

The advantage of using a PowerShell script is the possibility to do changes and improvements to the scripts directly on the server (but off course in a copied file) without having to do the changes first in a machine with Visual Studio, compile and so on.

Regarding the other answer posted, that you are in big risk that Microsoft changes everything and so on, this is just the same as any other code you write against SharePoint. You use the same API.

Also, these API:s are very stable. Actually very little has happend between 2007-2010 (ok metadata was added, which was a huge thing, but not much was removed). The same goes for 2010-2013, mostly added stuff and very little removed.

Normally Microsoft deprecates methods instead of removing them instantly as well, giving you a large window (a version) to update your code to confirm to the changes.

Answer 2

This solution screams "timer job" to me. Here is a guide I have used in the past to help creat them. I realize that it will probably take a little bit longer to conceive than a console application but there are several reasons to go the purely SharePoint route:

• SharePoint has, as has been noted, pretty decent about maintaining upgradeability from version to version. When I've upgraded farms from 2007 to 2010 for instance, bringing along the timer jobs was a simple matter of getting the .wsp file from the 2007 server and deploying it into the new 2010 server. 2013 has a similar dynamic. I'm told that MS is going to be moving away from the solution model in general so that may not hold true for 2016 but, knowing Microsoft, there's bound to be a period of deprecation where you can import old solutions, knowing you'll need to come up with something new (possibly re-using much of the code) for the new one.

• A console app or PowerShell script is by its nature going to be server-specific. This has its own host of issues. For one thing, what if that server goes down? At another job, I set up a console app job similar to the one the other poster has advised you to do which ran hourly. The result? Whenever that particular server went down, the job didn't go. Whenever it came time to reset the password for the login used by that job, it would stop working until I went in and did so (I did not in this case have access to an admin account to do this). I also had to give this login access to the list in question, access which could have been revoked by any other site collection admin. My only excuse there was that I was adding onto an existing solution and never really got the time to refactor it into something more stable like a timer job.

  I should point out here that I was also the SP admin on this particular job, so I still had the leeway to make all these changes myself. Which brings me to another point...

• Because of the issues above and, more importantly, because of the ability for a console job to break SharePoint and/or the server in creative ways that are much harder to do with a classic timer job, many companies will have rules against adding stuff like this. Part and parcel to that, many SP admins will understandably not want to deploy something like this even if it's not expressly against company rules. If you're not the farm admin, you should probably present your admin with a .wsp file rather than a .exe and a set of instructions.

That being said, if you're the administrator of a small farm and you need to get something up right now, sure, programming in PS or via a console app will probably be (slightly) quicker. I'd still advise you to learn timer jobs and eventually, when you do get the chance, refactor the solution into something SharePoint-specific.