I am trying to sync a sharepoint folder, "Testing" shown in the image below to my local device, but I have not been able to figure out how to do this.
I have looked at other sources and they said to find the "Sync" option, however I was unable to find this option. How should I go about doing this?
Edit: This is a shared folder that has been shared to me by another person in the organization, and can be accessed by multiple people
Had to read your post a few time but the answer is in the Edit section. The folder was shared to you by another user in the organization. This is most likely the reason why the sync option is not available. I'm a 365 admin in my organization and would make sure that users could not share SharePoint Doc Lib with other users and defiantly not be able to sync the library if the user could share a folder. This would be down to GDPR or Organization policy in place plus SharePoint Libraries will/should have user access in place. Being able to receive a share link from another user to me would mean that there is an issue with access to the SharePoint Document Libraries security/access settings.
If you return to classic SharePoint, you would see the "Sync" option.
To sync sharepoint folder to local device, you have to allow items from this document library to be downloaded to offline clients. Please go to library settings-> Advanced settings, make sure you select yes.
Related
I'm completely new to Sharepoint so keep that in mind when answering or assuming things.
Anyways, we have a CRM 2015 Online Update 1 and Sharepoint Online and those are integrated (not by me). Now when an end-user goes to Account -> Documents the CRM will automatically ask if the user wants to create a folder to Sharepoint. That's fine, but naming convention seems to be "AccountName_AccountGuid". We would like to change that to "AccountName_OurOwnID" where OurOwnID is a custom field in CRM that is unique for every account.
So my question is how would one do this?
EDIT: All I can think of now is to create a plugin that'll be launched when ever a sharepointdocumentlocation entity is created and basically create a new folder with wanted name and then delete the original folder in Sharepoint and then connect the new folder with sharepointdocumentlocation.
Sub-question: Is there a way to tell CRM to stop asking if the user wants to create a new folder? In my case it's unwanted feature but since it is there at least we should make sure that names of the folders will be ok.
The folder name with the guid is default behavior which cannot be altered.
If you want to develop a plugin, look at this post: https://crmconsultancy.wordpress.com/2011/10/27/crm-2011-integration-with-sharepoint-custom-document-management/
Keep in mind, if you want to create objects in SharePoint from CRM online you have two options:
Add the SharePoint.Client assembly with ILMerge. Officialy this is not supported.
Or use the rest endpoint of SharePoint. This is an interesting post to read: https://bingsoft.wordpress.com/2013/06/19/crm-online-to-sharepoint-online-integration-using-rest-and-adfs/
I have a requirement in a Sharepoint 2013 setup wherein I've to give access to external users to a document library. Each User will have a folder by their name, and would be allowed to ACCESS their folder ONLY. They are not even allowed to see each other folder names. They can anytime upload additional or delete the existing documents. External Users are setup using FBA.
Inside the network, there is a Windows user who'll have access to all the folders and documents of that library. I don;t think standard document library can handle this since there is no "Deny View" Permission in Sharepoint.
Sharepoint Folks - Please guide what will be the best way to handle this kind of requirement.
I don't think having a bunch of folders makes sense. However, you could have users upload documents to the shared documents library and have a column in the documents library of the user's username. You could then create a content query on that list to query documents that the current user uploaded. You could then replicate a "folder" type of feel by creating this page, styling it, and directing all users to it.
Let me know what you think of that.
There actually is a way to deny all users. Remove the Authenticated Users, and Remove Anonymous Access from the Library. I agree, that using folders is the wrong idea here. Folders can cause much more harm than help in certain situations.
Create a site to hold multiple libraries, or disinherit the site, remove everyone not essential to the libraries, and use it as a container for the document libraries. Each library can still have it's own unique permissions, and without Authenticated or Anonymous, you'r essentially telling SharePoint that none has access except for the users specified in the ACL's on that library.
You COULD leave the permissions intact on the site and powershell the creation of the document libraries within the site, assigning custom permissions.
Alright, I am obviously missing something here. I have moved several websites over to Azure to take advantage of all that it has to offer. Traditionally our team has always used DreamWeaver to ftp up/down and such. What I don't understand is how I go about getting hooked up to an EXISTING site on Azure. I can easily setup and web deploy to a NEW site, but I am trying to give the rest of the team access to the sites I have setup and I am lost as to how to approach this.
I have tried the File > Open Web Site route, and the issue with that is it never then saves the project/info anywhere in VS, and we are required to hook back up to it each time.
All of our local sites are on a shared network drive, so we all access the same local resources. I thought I could simply pass them all the publish profiles and they could then import, get, and then edit and publish files... but it never gives the option to "get all files" from the server.
Hope this makes sense?! Thanks in advance! :)
For multiple developer scenarios, it would be in your best interest to use a source control system such as Git or TFS. This will allow you not only to share the source across team members, but also give you the benefit of tracking changes and merging files that are modified across team members.
If you aren't comfortable with source control, you do still have access to the files via FTP or Secure FTP.
You could also use WebMatrix which has the concept of download from server built directly into the tooling.
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
I was wondering if anyone knows how to or if it is possible to upload files to a sharepoint (v3/MOSS) document library over FTP. I know it is possible with webdav. If it is possible is this even supported by Microsoft?
I don't think so. I think your options are:
HTTP (via the upload page)
WebDAV
Web Services
The object model
You can map a drive to a SharePoint document library, for example \\serveraddress.domain.com\Documents. So I would try mapping a drive on your FTP server, then making sure files that come in over FTP get sent to that drive.
Big edit: Have any of you figured out how to upload to SharePoint (WSS)? I've tried drive mapping and then using Robocopy and Synctoy to copy files thinking a tool might offer greater control (i.e. a Copy Date Modified control). As I understand it the files are actually stored in SharePoint as database objects and therefore SharePoint views display the database object (SQL object's) properties in Document Libraries where a new user would expect to see the file properties. Those file properties are still alive! They just need to be uncovered by a different view. I particularly like the mapped network drive view of a SharePoint Document Library. File attributes are pretty important to my team, so we were concerned about that at the start. As an opinion note though, the default view showing attributes that appear as incorrect is just plain annoying!
The best solution we've come up with for doing large file migrations into SharePoint is a mapped network drive then using a tool called FreeFileSync available at SourceForge to move your files and folders. It's great because it produces verbose error messages and give a lot of control, especially for the instances that SharePoint tries to block a particular filename or file extension.
Direct FTP into SharePoint is not one of your options. You would need to have a timer job run that checks your FTP directory and uploads into the document library.
Yes it is possible.
The WebDav Redirector allows you to access webdav resources (including Share Point) via UNC path, ie \yourspserver\site\doclib. The IIS FTP server accepts UNC paths as backing storage to virtual directories.
On your ftp server, right click the ftp site in the IIS Manager and select "Add Virtual Directory". Give it a name and specify the sharepoint unc path for the physical path. You'll need to set the "connect as" user to a domain user that has access to the sharepoint folder you're connecting to.
Connect to the ftp folder and you should be able to "cd" into the directory and put/get files without issue (just confirmed it myself). The only caveat is an age old bug/feature of IISFTP, that doesn't show a virtual dir in an ls/dir command listing. The fix is to create a physical folder that mirrors the virtual directory's location. For example, if your ftp root is c:\inetpub\ftproot, then you'll need to create a dir that matches the name of your virtual dir in this location. It will then show up in an ls/dir listing but the cd command will still move into the virtual dir, not the physical dir.
You can directly SFTP/FTP into your SharePoint doc library using Couchdrop. It turns your SharePoint into a native SFTP/FTP server, you can create additional users, etc. Sing out if you need assistance more than happy to assist.
Full disclosure: I represent Couchdrop