Does anyone out there find it useful to sync' SharePoint sets (lists, documents, etc.) with "external" sources like the file system? What about SharePoint-to-SharePoint sync? Do we have any explanation why Microsoft Sync Framework lacks any serious hooks into SharePoint? Is this stuff coming out in some Office 14 timeframe? Under NDA?
Haven't tried it yet, but have you seen?
http://listsync.codeplex.com/
Related
Is Sharepoint my best option to replace an aging network of fileshares? There's approx 1TB of data residing among 3 fileshares (1 DFS, 2 NAS boxes). A document management system is in place for new things - the file shares are now just read-only archives/legacy. Our users would simply need to be able to search for and open the documents.
Users are finding it difficult to locate their documents in the file shares and windows search does not often help. Sharepoint was suggested as something which would play nicely with Office documents (99% of the content) and have a good search facility.
Not being a Sharepoint Developer or having had any training on it, I'm getting a little lost. I have set up a test server to try it out using SP2013. I have managed to index each of my file shares and have created a search page. However, results aren't consistent with the indexted items. I assume I need to somehow get the relevant metadata from the files but I have no idea how to go about this.
Could anyone suggest some resources for help on this subject (my searches have mainly turned up paid-for Sharepoint addons or outdated blogs) and any experience of doing something similar? Also happy for any suggestions on ways to achieve this using other software/platforms.
I went with Microsoft Search Server 2010 in the end.
Sharepoint is basically optimized to be a document manager. I think you don't need to buy or donwload addons.
For your problem, metadata are the key! You need to properly specify the metadata.
I give you the theory of a plan document management in SharePoint 2013 :
https://technet.microsoft.com/en-us/library/cc263266.aspx
A nice introduction to metadata :
http://fr.slideshare.net/gzelfond/document-management-in-sharepoint-without-folders-introduction-to-metadata
Be careful to use the Microsoft documentation for the beginning. From my experience, its difficult to start with this documentation because you have several things in it. There is also good books/ebooks that you can find easily to start well, and probably more simplified than MS documentation.
I went to the Microsoft Visual Studio 2010 launch event in Minneapolis yesterday and was slightly surprised by how much they were trotting out SharePoint and improved SharePoint development in Visual Studio 2010.
SharePoint is something I've largely ignored over the years as a web developer and solution architect on a small development team. I was always under the impression that SharePoint was used mostly for intranets in large corporations, and that if you were developing for SharePoint, it meant that a corporate decision had been made to use it and you as a developer probably had few (if any) options.
I realize this assumption is probably incorrect. So, what are the "cool" uses for SharePoint? What unique business problems have you solved using it? What could make a developer excited to be working on something for SharePoint?
Document libraries in a Microsoft environment. There are many nice out-of-the-box features for managing documents.
Intranet sites that have permissions setup in such a way to allow business entities to control use of the site within their group.
Project requirements lists. List in SharePoint can be customized to some degree without ever programming.
As a conclusion so far, SharePoint is a blessing and a curse. It has a lot of value-adds, though anything outside that box is difficult change, but there are indeed many 'hooks' to do just that. WSS3.0 is free for Windows Server 2003, as is SP 2010 Foundation for Server 2008, so you can get quite a bit out of that without upgrading to MOSS or 2010 equivalent.
It's probably best used in intranet/extranet scenario's, true. There's many public facing internet sites built on it as well, if you find that cool :)
See http://www.topsharepoint.com/ (I built one of the top-10 sites ;)
It's definately not the best web content management platform but it is not bad and companies like people who have learned to manage their intranet to be able to seamlessly do the same for the internet site.
Personally I find it "cool" that I can deliver functionality quickly and without building the world from scratch (I've built enough document management solutionettes and prefer not to do it ever again). But if I have to custom build there's many footholds for customization and all of the .NET platform is available. There's workflow solutions that allow business users to customize their own workflows and not bug me with them. I'm sure there's plenty of other solutions out there that can do something similar but the integration with Microsoft Office and the rest of the Microsoft world is quite good IMHO.
I don't understand the antagonism against SharePoint and find it's mostly fueled by ignorance and people trying to use the platform for something it wasn't meant to do (like being a relational database). You will have to learn it; it's not like adding ELMAH to your project, it's a really big layer in your architecture.
I work for a large organization and we have been utilizing SharePoint for document library. Yesterday my boss called me to his office and asked me:
"I heard that SharePoint is an ECM! So what can it do for us?".
"What kind of problem do you want us to solve utilizing SharePoint?", I replied.
"I want to know what it means when they say it is a ECM and how it can help us?", He said.
I told him it has Document Management, WorkFlow, Records Management, Search and some other stuff.
Anywho, He wants me to put togetter a list of things that SharePoint offers as an ECM.
You might find some useful info on the MS ECM team's blog.
Microsoft Office Sharepoint Server has a substantial content management system available. What was previously Microsoft Content Management Server was discontinued and that functionality was put under the Sharepoint umbrella. Usually this is referring to web content, but it can honestly be any kind of content relevant to an enterprise. It is intended to be a direct competitor to all the major WCMS out there, focused especially on the enterprise (governance, auditing, security model, etc).
That having been said, the current iteration of MOSS's EWCM pretty much blows. If you can develop your CM strategy to be parallel to MOSS, it can work out OK, otherwise it's much more pain than it's worth. Use SP for document management and use something else for content management.
Sharepoint is a collaboration platform restricted to a windows environment
Give Alfresco communities (labs) a go is my opinion here as it 'acts' as a Sharepoint server so Microsoft Office suite will not notice the difference but your wallet will...
Er... think the boss got a bit too much $$$ to spend. But really, an't we supposed to deploy a technical solution to solve a business problem.
The list of features can be found at
http://sharepoint.microsoft.com/product/capabilities/Pages/default.aspx
One of our product will consist of multiple SharePoint solutions. Now we're wondering what would be the best way to provide an easy deployment to our customers? At the moment we deploy each solution by hand, which is OK during development process but not acceptable for our customers.
For your information, we're using VSeWSS 1.3 for development and solution packaging.
So how do you offer your solutions to your customers? Do you write installation scripts using STSADM commands? What other options do we have?
WSPBuilder
Personally I use WSPBuilder for packaging and find it much easier to work with than VSeWSS. However if VSeWSS is working for you then that's great.
One of many the benefits I found of using WSPBuilder is that it's easy to integrate into a build system. It's just a simple, but clever, commandline tool.
Batch File
For deploying multiple SharePoint solutions to our customers I usually provide a batch file that contains the necessary STSADM command and prompts them to enter any environment specific data i.e. site collection urls etc...
SharePoint Solution Installer
There is also a nice GUI installer,called SharePoint Solution Installer, that you can use in-conjunction with SharePoint solution files. Check it out it might suit your needs.
alt text http://i3.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=sharepointinstaller&DownloadId=18625
SAF - SharePoint Action Framework
It's worth pointing out SAF; which is an extremely comprehensive framework that can automate installation and configuration tasks, using either MSBuild, Powershell, Stsadm or a custom SharePoint feature.
We just use plain old batch/cmd files. If you need to "productize" this, just wrap up all solutions in a selfextracting rar package and have it run the batch file after unpacking.
Stick to Microsoft products. Powerbuilder is being groomed to gradually take over from STSADM for this type of task. In a farm scenario (remember, yours may have to grow over time), this would be the tool to use to push out solutions to all front-end Web servers.
EDIT:
MS are preparing a final version of VSE 1.3 to ease the migration of 2007 solutions to the 2010 environment.
Have you looked at Microsoft SharePoint Designer?
not sure if it will do all you need, but it does allow you to package sites or individual objects that you can then run on another SharePoint install.
Does anyone have any strategies/tips/traps for moving to Team System? Should it be done in baby steps, or all at once? Should we migrate our SourceSafe library over, or draw a line in the sand and move forward? Is it worth brining SharePoint into the mix? Any thoughts are appreciated.
I've never had to migrate to TFS, but have used it pretty extensively for the past couple of years.
Regarding your question on Sharepoint, we've found it pretty useful in conjunction with TFS. We use it primarily for documentation management and for storing other "non-technical" artifacts related to the project. Some dev teams advocate keeping documentation in source control alongside source code, which is OK, but in my experience our project stakeholders have an easier time accessing relevent project documentation via the Sharepoint portal than they would having to interface with source control.
I basically was able to distribute the URL to the sharepoint site associated with our TFS team project to the concerned non-technical team members and have been able to avoid constantly e-mailing documents around, so it's been great for us.
It may just be too much work to do it all at once.
I feel that it is easier to divvy out projects to different people one at a time.
That way they can move them across and ensure that each works okay before closing out the SourceSafe.
You will always want a backup of the SourceSafe "database" around just in case.
I do not know how to migrate from SourceSafe to TFS and keep the comments and versions.
By far the easiest it to just add the projects in, but having migrated that way in the past, we always missed the ability to find out what others had done to particular files.
If you find a way to migrate, I would go that way unless it is hideously expensive.