Azure & Office 365

Archive for the ‘SQL’ Category

1. Purpose and Usage:
   • OneDrive App for Teams:
     • Designed for individual workspace and personal file storage.
     • Ideal for files used by a single user.
     • Great for business documents, drafts, and personal reference.
   • Files in Old Teams:
     • Used for collaborative work within channels and teams.
     • Shared files accessible to multiple team members.
     • Suitable for ongoing projects and long-term collaborations.
2. Access and Integration:
   • OneDrive App for Teams:
     • Seamlessly integrates with Teams.
     • Provides easy access to all Microsoft 365 content.
     • Replaces the existing Files menu item.
   • Files in Old Teams:
     • Accessed directly within Teams.
     • Linked to SharePoint libraries behind Teams and channels.
3. File Ownership:
   • OneDrive App for Teams:
     • Files are owned by individual users.
     • Account holder’s departure doesn’t impact shared links.
   • Files in Old Teams:
     • Files are owned by the team or channel.
     • Shared links may be removed if the account holder leaves.
4. Collaboration:
   • OneDrive App for Teams:
     • Limited sharing—best for personal use.
     • Collaboration features are minimal.
   • Files in Old Teams:
     • Robust collaboration tools.
     • Multiple users can work on shared files simultaneously.
5. Future Enhancements:
   • The OneDrive app enhancements will roll out to classic Teams in early 2024, with the Files app name unchanged.

Business Documents app in Teams is a new app that allows you to create, edit, and share business documents with your team members and external partners in Microsoft Teams. Business Documents app in Teams is powered by SharePoint Syntex, a new service that uses advanced AI and machine learning to automate content processing and transform your content into knowledge. With Business Documents app in Teams, you can:

• Choose from a diverse array of templates to craft essential business documents, including proposals, contracts, invoices, and reports. Additionally, the option to devise personalized templates for future utilization is at your disposal.
• Within Teams, leverage the Microsoft 365 suite encompassing Word, Excel, PowerPoint, and Visio to modify your business documents. Engage in real-time collaboration, enabling concurrent editing, commenting, and effortless tracking of revisions and versions alongside your team members.
• Empower secure dissemination of business documents to both internal collaborators and external associates through Teams. Exercise meticulous control over access and permissions, employing encryption and Azure Information Protection to safeguard sensitive data and avert potential leaks.
• Harness SharePoint Syntex to systematically capture and standardize crucial metadata for your business documents, encompassing document type, status, ownership, and more. This empowers seamless filtering, sorting, and retrieval of documents, and facilitates the application of compliance labels and retention policies.
• Utilize SharePoint Syntex to extract invaluable insights from your business documents, including dates, monetary figures, names, and other pertinent information, enhancing the efficiency and efficacy of information retrieval.
• Extract valuable information from business documents: You can use SharePoint Syntex to extract valuable information from your business documents, such as dates, amounts, names, and more. You can also use this information to create custom views, reports, and dashboards, and to trigger workflows and actions with Power Automate.

Hi All,

 

In this article I would try to share my experience about SharePoint on SQL RBS. This article may help you decide if you should use SQL RBS with SharePoint or any other product.

 

This is my personal opinion about SQL RBS with SharePoint. I would suggest you to cross check below furnished details before taking final decision. Microsoft keeps enhancing its product so some of these may be fixed\resolved\changed.

 

Let’s first discuss what is SQL RBS? Normally when you upload a document, image, video, audio, etc on your SQL server it is stored in MDF (Master database file) of your SQL content database. As per my past experience when you upload anything to a content management system, you would revisit only 20 % of data uploaded, rest 80 % of data is never visited but used for record only purpose. IT pro’s suggest that you should keep your SQL content database on RAID 10 hard disk or SAN which is pretty expensive.

 

To resolve this issue Microsoft came out with SQL RBS which allows you to store your Files\BLOB outside (File system) of SQL database. This means you can use a Raid 0 drive to store BLOB files (image, video, document, etc). RBS is intended to lower storage costs by allowing you to store large read-intensive BLOBs on less expensive drives.

 

1st Myth of SQL RBS: Additional Storage for Content database.

This is the biggest myth about SQL RBS. Microsoft Suggest that your content database should be below 200 GB. Now days when we have a USB stick with 100 GB, a Content management server restricted to 200 GB is not a good deal. To overcome this issue few IT admin plan to use SQL RBS because RBS stores files outside of SQL server hence decrease the size of content database.

Reality: RBS does not increase the storage limits of content databases. All limitations still apply to RBS-enabled content databases. If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed the 200GB limit.

 

2nd Myth of SQL RBS: Files stored on FILESYSTEM through RBS cannot be accessed directly.

IT Pros and lot of other articles says that we cannot open the file directly from BLOB FILESYSTEM. We have to go through SQL database in order to read these files.

Reality: I was able to access FILESYSTEM where the BLOB files were stored and was able to open my txt, bmp, jpg, etc files. SharePoint is known for its Item level Security. So far SharePoint security was never compromised and access is only available on need to know basis. If any users who has access to FILESYSTEM can open any file stored in SharePoint without having access on SharePoint is a security issue. Also encryption is not supported on BLOBs, even if Transparent Data Encryption is enabled.

 

3rd Myth of SQL RBS: Better performance I hear a lot of IT PRO who comment that they would get better performance if FILES\BLOBS are stores outside of SQL Server.

Reality: I would accept this when we are using SharePoint to store Hugh amount of data files (70-80 % of BLOB). When I asked these IT Pros how much data is stored on dbo.docs, dbo.AllDocStreams, dbo.DocStreams, dbo.AllDocVersions, dbo.alldocs, etc table, they are not aware of same or they don’t bother. When you offload 70-80 % of data from your MDF file and store it FILESYSTEM you may feel better performance. If our content database stores BLOB files not more then 30-35 % then it would not make sense to go with RBS. Let me explain you why I say that, when you configure RBS you create number of additional tables on your content database. This means when we upload BLOB to SharePoint it will execute additional query to store data. Here SQL will first import image files, and then it may split the file based on size of file and then store it to FILESYSTEM. Again this process is reversed when we try to open or query the BLOB file. This will increase disk IO, RAM and processing power. Now if consumption of my resources is increased, how can I expect better performance? RBS does not support using data compression but data is compressed when uploaded to SQL MDF file. Microsoft says “Although using RBS with files larger than 1 MB can improve I/O and processor performance, using RBS with files smaller than 256 KB might decrease overall performance. Storing the BLOBs inline in the content database is more efficient with smaller files”

 

4th Myth of SQL RBS: Ease in management

A lot of IT Pro’s also comment that it is easy to manage smaller SQL databases, Better Technology, Ease in configuration, etc.

Reality: Why you want to take an additional Load of configuration anything extra on SQL. If any feature is available does not mean you should use it. Implementation of these features depends on its pros\cons and specific requirement of the feature. Also when you backup the database, it will backup all the files from FILESYSTEM along with SQL MDF\LDF files. Sizes of these databases backup does not decreases but it increase because RBS does not perform any compression. If you plan High availability through Mirroring or Log shipping, you need to follow additional steps to configure the same.

That’s it from my side. Feel free to comment or connect with me if you feel any of the above information is incorrect.

Reference:

https://technet.microsoft.com/en-us/library/cc262787.aspx

https://technet.microsoft.com/en-us/library/ff628583.aspx