I've just uploaded several hundreds of files to my Sharepoint Online libraries. I was wondering what would be the best solution to have them syncronized or kind of a network drive in my WS2008.
Microsoft recommends using the OneDrive Sync client, so here is the Link to the install instructions from MS as a standalone package. Choose the 32-bit version even if your OS is 64-bit. In my experience with Office rollouts it is still (!) the version giving the least amount of headaches.
Using the OD4B client the files you choose will synchronize to the server. Please note that it is a two-way-sync and if you delete something on the server this will be done in SharePoint as well.
Map to network drive (i.e. via WebDAV) is still possible in SharePoint Online, but it is not reliable and disconnects often due to authentication requirements.
Related
I have read the entire VSTO documentation to start with and skimmed over most of the Office Add-ins (office.js) documentation on MSDN but not found the answer to my question.
Could you please provide me with an answer and also, if possible, please point me to the page on MSDN that answers my question?
Question
In a scenario where the client computer does not have Microsoft Office installed, and is using a browser to access Office Online, and he loads an Office add-in written using Office.js, in such a scenario, where is the computer that hosts the COM objects and the Office process they reside in?
Here is my understanding of the elements involved in using Office.js add-ins:
There's the Open XML document that has the data. This is just dead-meat. It had to be loaded into a process.
Earlier, that process used to be the unmanaged WINWORD.EXE (or EXCEL.EXE or POWERPNT.EXE or another office application) process.
Now, with office.js, when using Office Online, i.e. the Web client, the unmanaged Office process still has to be allocated in memory in some computer? Basically, that's the core of my question.
My guess is
that it has to, and that the process may be run remotely on a
server. The document itself may be hosted remotely, which isn't a
big deal but the process, too, is required and in the case of Office
Online, the unmanaged office process is run on a remote computer. It
is this assumption I want to confirm or invalidate.
There's the client UI. This used to be a mesh of unmanaged C++ code within the office application and managed UI created by .NET using VSTO and Windows Forms or WPF. Now, with Office.js, this is done using HTML/CSS/JavaScript and can be loaded by any kind of a client (desktop/Web).
The process hosting the document and providing the underlying Document, Bookmark, Range et al objects. My question is -- for Office Online clients that do not have MS Office installed on the client computer, where is this process now if they use Office Add-ins written using office.js?
Am I wrong in assuming that the JavaScript API for Office Add-ins merely calls into the existing Office COM infrastructure we already know about? If I am right, then where is the machine that hosts the Winword.exe (or whichever Office application) process?
To answer the question of where the code is executed: There are no "COM" objects per se (the new wave of Office.js APIs is not based on the VBA COM objects, at least not directly). But there is indeed a backing server that has the document open and in-memory. In the case of Excel, the Excel Online front-end is a fairly "thin" layer, and almost all operations are executed by the supporting server. That server doesn't run EXCEL.exe directly, but it has a web service that is kinda-sorta-like Excel (and that shares a lot of the same underlying C++ code), which runs in a "headless" mode, one instance per document. In the case of Word, on the other hand, Word Online has a lot more business logic that it can execute locally, and so a lot of the operations are executed on the browser and sync back up to the server at idle time (much like end-user operations), but there is still a backing server that serves the appropriate data to the Word Online front-end, and that processes some operations (e.g., range.getOoxml(), or image.getImage()).
Hope this helps.
Office Web Add-ins (office-js) are web apps that leverage a specific library (office-js) to facilitate communication between the add-in and the host application.
As these add-ins are simply web apps, they work across the various Office platforms (Windows, Web, Mac, iOS). For browser based Office editions, add-ins are surfaced in an iframe. For native editions they are hosted in an embedded browser (IE11, Webkit, etc. depending on the platform).
Add-ins consist of two components, an XML manifest and the web app. The manifest can be loaded from a number of locations from directly side-loading, to a network share, to the Office Store. The web app is hosted wherever you would normally host your web apps (I recommend Azure but then I'm a bit biased). They are never hosted by Microsoft directly.
Let's take Excel for example. In Excel 2016, when I select an add-in in the STORE, after clicking on Trust It, will the code (.html, .js files) of the add-in be downloaded or installed on my machine?
In other words, have the add-ins under MY ADD-INS been already installed on my machine, such that i could load and run them without Internet (if an add-in does not send or receive special data to or from Internet)?
I am asking this question, because i want to know if a basic add-in always requires Internet access to work.
As Eric mentions, Office add-ins are indeed web based. However, to add a bit to his answer:
While you definitely need a one-time access to fetch the manifest and the original HTML/JS/CSS files, if your add-in is not using license checking (it's free) and does not require web services, you should be able to make a website that uses standard offlining techniques to load with no internet connection after the first time.
I tried it out real quick with pointing a manifest at http://html5demos.com/offlineapp. After loading it once and then disconnecting my internet, I was still able to load that page.
Hope this helps,
~ Michael
Yes, the new Office add-ins are web-based. They are all defined - and installed - by a manifest file which specifies the URL location of the web source files. These are always hosted on the provider's web server and are not cached for offline use. The licensing system used by most add-ins (the ones that aren't free) requires a connection to the provider's web server which in turns needs to verify the user's license against the Office Verification Licensing Service. If offline use was enabled users could use a trial license in perpetuity without the provider being aware.
I had two clients with a save issue in SharePoint.
When they try to save they would get a a very generic error: "Document Could not be saved"
The only way they could get them into SharePoint was by:
Saving to local File System
Using the Upload option from the SharePoint menu
Configurations
Client 1: Vista and Office 2007
Client 2: XP and Office 2003
I was able to fix client 1 by having him Map a Network Drive to the Sharepoint Site.
After mapping the network drive, somehow the OS magically knew about the SharePoint documents folder and he was able to save.
I'm not having the same luck with Client 2.
It won't even let me map the network drive. I get an error (one that I did not take a screenshot of and don't remember the exact wording...sorry). but it was an error trying to map the network drive to the SharePoint site.
So, after some Googling, I had him go to Windows Update and download all the latest patches for his OS.
He claims he did, but is still getting the problem.
Before I do another WebEx and start taking stabs in the dark to try and fix him, I was wondering if any veteran SharePoint users have run into this same issue and what they did to fix.
Or, is there some OS setting I should be looking at that needs to be toggled/modified.
I can access his SharePoint site just fine from several PCs and make modifications and save as necessary.
Did you try running the Microsoft Office Diagnostics?
Start --> Microsoft Office --> Microsoft Office Tools --> Microsoft Office Diagnostics
Let that scan and repair any issues it finds and see if that helps. That tool has fixed similar issues for me many times.
I have been investigating building web parts for sharepoint 2010 and currently have a single instance of SP2010 on the work servers. I would very much like to be able to test them locally (on my laptop) if possible, without having to install sharepoint 2010 on my laptop (is this even possible?!)
Is there a way to test web parts and do I need to install all/part of sharepoint on my laptop?
Thanks
If your Web part is simply displayed in a SharePoint page, without using the SP API, you could simply host it in an ASP.NET page on your laptop, but this is not a common scenario.
One new feature of SP 2010 is the client API, i.e. a subset of the full API that can be used outside of the farm. If your usage of the API fits in this subset, this could be useful, but you will still need to access a SP server somewhere.
Another option is to put all the code that uses the SP API in something similar to a Database Access Layer which talks to SP on one hand and returns business objects (not lists or lists items). This way, you could simulate this part on your laptop and concentrate on the look of the Web part and its business rules, without SP. If this part is in its own DLL, the only reference to SP DLLs would be there, so the project on your laptop would not need to reference the SP DLLs.
There are two ways: the good one and old-school.
The good way is to install Sharepoint Services (http://technet.microsoft.com/en-us/windowsserver/sharepoint/default.aspx) and deploy WP locally. It works only if you have Windows Vista or Seven. It is the most productive way so i recomend it.
Another way comes from SP2003 era... The idea is to develop custom Web Control, test it locally with IIS or just development server, and then to embed it into web part. The method is described here - http://www.reflectionit.nl/SmartPart.aspx . It's an old and painful method. Unfortunately we can't use (without troubles) Microsoft.Sharepoint.dll etc
P.S. Sorry for my English...
This came up at our office and we ended up installing Sharepoint Foundation on each developer's PC, which allows us to develop and debug locally. Here is the link that I used to get this working.
Setup Dev Env. For Sharepoint Foundation on Win 7
I would say get a virtual machine.. but I dont think you can run 64bit VM's on a 32bit OS.
You'll have to upgrade to 64bit.
I don't think there is a good way around this; you will spend a lot of time on something of questionable value if you do not install SharePoint either on your laptop or in a VM and do it the proper way.
You can just swap out the inheritance from the SharePoint Web Part to the ASP.NET equivalent and back again - all the functionality is the same because the newer version was designed with backwards compatibility in mind. Use the ASP.NET version when testing on your laptop.
Here is some more info :-)
http://weblogs.asp.net/scottgu/archive/2006/09/02/Writing-Custom-Web-Parts-for-SharePoint-2007.aspx
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