I have a sharepoint site that I'd like to migrate to a new tenant. I read that I'll have to use third party tools like Metalogix to do it properly. Are there any alternative ways with which I can achieve this, preferably without a third-party tool? I just have two sites with few contents and couple of apps. I found sharepoint migration tool: http://spmtreleasescus.blob.core.windows.net/install/default.htm But I'm not sure if it's used for tenant-to-tenant migration.
With two sites and perhaps a few document libraries, perhaps a manual migration would work: Manually create the destination sites/libraries, and for a given library, sync it. Since it's a new library, there is no content to sync, but it will create the folders, etc., on your local machine via onedrive. Open that location with windows explorer. Then, go to the source library with Internet explorer, and use the open with windows explorer command. (or, sync it also). Then, simple copy the files from the source to the target library in the windows explorer onedrive view. OneDrive will take care of syncing the files up to the library.
If have a bunch of libraries, or if you need to preserve things like file created dates, then the 3rd party tools are helpful. Another popular one is ShareGate.
The third party tools can often also copy metadata, versions and Content Types.
Some of these tools have free, for limited amounts of data, trial versions.
Related
bulk download from share point not downloading exact files and error.txt files are generated.
is there any application to bulk download sharepoint files
https://i.stack.imgur.com/cnOyy.png
https://i.stack.imgur.com/X5wf2.png
You can use the Open with Explorer function to open the document library in Windows Explorer, where you can select all the files you want and simply copy them to your destination. Note that this function only works in Internet Explorer, not in Edge or any other browser. There are ways to make it kind of work in modern browsers, but that requires custom code. You can, however, save the location of the document library to the Quick access list to make it easier to find.
Another option seems to be the SharePoint Bulk File Download web part, but I believe this is a paid tool that must be purchased after the trial.
I use Open with Explorer all the time, but I have never tried the mentioned web part.
We have a requirement to store documents in SharePoint Online as people copy files to a shared network directly.
Is there a way of automating this? I was thinking of a windows service which will poll the directories, find any changes like new subdirectories or new files, then upload them to a SharePoint Online document library.
You don't have to poll if you use a FileSystemWatcher inside your Windows service for real-time notifications.
http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx
However, if your requirement is 100% accuracy, you will need to build in some sort of tracking/checksum mechanism to make sure that every document was 1) detected and 2) successfully moved to SharePoint.
You may want to have your service check the delta every time it starts up, and then subsequently only respond to FileSystemWatcher events.
EDIT: Per Tony's question below, here are some additional thoughts on getting files to SharePoint.
First, try a simple test.
1) Copy the URL of a document library within the BPOS SharePoint site. Make sure you're on a machine that has the Office Online sign in app on it.
2) Open Notepad. Type some random text.
3) Click on File -> Save As.
4) Paste the URL.
5) Attempt to save the file.
This works great on "regular" SharePoint (done it many times). If this works with BPOS, it opens up several options.
File System Replication to a SharePoint Online or Office 365 document library is planned to be released with the "Cloud Connector for Office 365". With the current version database content is supported only, but bi-directional with V2.0
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.
I need to work with several teams and need to be able to share requirements and design documents. Most people won't be too technical, so I want to avoid source code tools. The main requirements are:
Easy sharing via links. I don't want people to have to install multple tools just to see a file or learn anything about svn checkout.
Permissions - I want to allow view only access to most people, with some having add/edit permissions. I don't want anyone to be able to permanently delete anything.
Revision History - I want to see who has added and edited files and be able to revert to previous versions.
I've tried Dropbox and SkyDrive, but they each have faults. Dropbox allows users to permanently delete files, and it will even delete the file from your local machine when it is synced. SkyDrive doesn't allow enough fine grained permissions or revision history. Do I need a CMS system like Drupal]? Would Sharepoint be the proper tool? I don't necessarily need an open source solution. The easier it is to set up and administer, the better.
Just my personal bias, but I hate Sharepoint. (I see this Q is tagged Sharepoint)
I much prefer some sort of Wiki, and have had good experience with TWIKI. It certainly meets the three basic requirements.
AFAIK Dropbox never deletes files "permanently" but you can undo it via the web interface. If I remember correctly you also can restore old versions of files but I cannot try it right now.
Adobe Buzzword might do most of what you are looking for.
If you do not need online document creation, a traditional CMS is not really what you are after. Drupal could serve your purposes, but it would not be straightforward- afterall, file attachments are second class citizens for a web content system.
Alfresco is a system I've heard used as a competitor for Sharepoint and useful for managing documents.
I'm in the process of moving a complete sharepoint install to a different server.
Can anyone tell me if it's possible to just move the existing Shared Services Provider rather than starting from scratch?
All the best
You really need to move the SSP in concert with everything else in the farm. The two things to move are 1. databases and 2. the file system.
A .doc file for moving all of the SharePoint databases has been published here. Microsoft will soon have an updated procedure for this published on TechNet, according to the To The SharePoint blog.
Then to cover off any file system changes, I would set up a clean install of SharePoint (if you didn't need to already by following the document mentioned above) and do a file comparison between your source and destination SharePoint application servers. I usually use WinMerge as its free but Beyond Compare is also good. Also check any custom solutions are deployed on your destination server.
By ensuring your databases are moved correctly and all of your files are in place you should be OK. Make sure you test every custom component on your destination server before erasing the source databases and files (even better, archive the source).
Yes, create a new SSP and move the applications.
How to on migration of applications here
For moving the SSP to a new farm
Or try the Microsoft SharePoint Administration ToolKit v2.0
For another view of this