Azure & Office 365

Posts Tagged ‘sharepoint’

Microsoft Purview, a family of data governance, risk, and compliance solutions, is introducing new features to enhance its visibility and control over cloud security activity events for Microsoft Exchange and SharePoint. These events are generated by the Purview Audit service, which monitors and records user and system actions across various Microsoft 365 workloads.

Previously, Purview Audit offered two types of licenses: Audit Standard and Audit Premium. Audit Standard provided basic auditing capabilities for common events, while Audit Premium offered advanced auditing features for more granular and sensitive events. However, some customers requested access to certain events that were only available for Audit Premium users, even though they did not need the full functionality of the premium license.

To address this feedback, Purview Audit is expanding its event coverage for Audit Standard users by adding four new events that were previously exclusive to Audit Premium users. These events are related to Microsoft Exchange and SharePoint activities, and they are:

• MailItemsAccessed: This event occurs when a user or a delegate accesses one or more mail items in a mailbox. This event can help detect unauthorized or suspicious access to email messages.
• Send: This event occurs when a user sends an email message from their mailbox or on behalf of another user. This event can help track the source and destination of email communications.
• SearchQueryInitiatedExchange: This event occurs when a user performs a search query in Exchange Online. This event can help monitor the search activities and keywords used by users.
• SearchQueryInitiatedSharepoint: This event occurs when a user performs a search query in SharePoint Online.

These events will now be available for all Audit Standard users, regardless of their license type.

This implies that clients with only an Audit Standard license can attend these events without needing to upgrade to an Audit Premium license.
Nevertheless, clients holding an Audit Premium license will still receive added advantages over Audit Standard users.
One of these perks is the capability to access a greater number of metadata fields for specific events.
For instance, for the MailItemsAccessed event, Audit Premium users will have visibility into the SensitivityLabel field, indicating the sensitivity level of the accessed mail item.
This feature aids in identifying and safeguarding sensitive or confidential information in email messages.
Another benefit includes access to additional events not accessible to Audit Standard users.
For instance, Audit Premium users can monitor events connected to eDiscovery activities, such as eDiscoveryCaseCreated, eDiscoveryCaseUpdated, eDiscoveryHoldApplied, and eDiscoverySearchStarted.
These events assist in tracking and auditing the legal discovery procedures and activities carried out by users.
By broadening its event coverage for Audit Standard users, Purview Audit seeks to offer more flexibility and value to its clients seeking increased visibility and control over their cloud security activity events for Microsoft Exchange and SharePoint.

By expanding its event coverage for Audit Standard users, Purview Audit aims to provide more flexibility and value for its customers who want to gain more visibility and control over their cloud security activity events for Microsoft Exchange and SharePoint. Customers can choose the license type that best suits their needs and budget, while still enjoying the benefits of Purview Audit’s comprehensive and integrated auditing capabilities.

Hi All,
I hope you all know that now we can create a SharePoint 2016 VM on Windows Azure. In case you have not tried it yet, you can follow below:

Select New on Windows Azure > Compute > Virtual Machine > From Gallery > Select SharePoint from left hand navigation > Select SharePoint Server 2016 IT preview


While I was working with this VM, I came across an issue where I was unable to configure a SharePoint 2016 farm using the SharePoint 2016 VM created in Windows Azure using one of their template. I found that root of issue was Active Directory. SharePoint cannot work without active directory and not everyone using Azure creates a VM with AD in Windows Azure itself. If you plan to create an AD forest in Azure and then add SharePoint 2016 VM to that domain, please follow my article:

Creating a Lab on Windows Azure
http://blogs.msdn.com/b/mvpawardprogram/archive/2015/02/09/creating-a-lab-on-windows-azure.aspx

 

If you are planning to use this VM only for learning purpose then you may want to create a SharePoint farm without Active Directory. Unlike previous versions of SharePoint, you cannot use Single Server install model to create a SharePoint farm without Active Directory or without installing SQL server.

 

 

To overcome this issue you need 1st install SQL Server and then use below PowerShell command to configure your SharePoint farm. You can download SQL server from below link

https://www.microsoft.com/en-in/download/details.aspx?id=42299 

 

Once SQL server is installed and your local admin account has access to SQL server, you can use SharePoint PowerShell to create tour SharePoint 2016 Farm.
1. Open SharePoint PowerShell as Admin
2. You may want to type below command and provide actual values. When you execute the command, you will be requested for credentials of your local admin account you used while creating this Virtual Machine.
New-SPConfigurationDatabase -DatabaseName “SP2016_config” -DatabaseServer “Name of SQL Server” -Passphrase (ConvertTo-SecureString “Sharepoint@2016” -AsPlainText -force) -LocalServerRole SingleServerFarm -FarmCredentials (Get-Credential)

Note: I have observed that when people try to copy paste such commands, hyphen(-) sign does not work, so remove and add these sign again in whole command.

Once above command is executed successfully without any issue, you can execute SharePoint PSconfig wizard and complete SharePoint farm configuration.

Hope this will help you.

 

Hi All,

 

Recently I got below error message which you might have seen. This is a very common and generic error message which can confuse you a lot. You may face this issue in all versions of SharePoint like SharePoint 2007, 2010, 2013 or SharePoint 2016. First let us look at the error message
#################### Error Start #############
Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be view able on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”.

<!– Web.Config Configuration File –>

<configuration>
<system.web>
<customErrors mode=”Off”/>
</system.web>
</configuration>
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the “defaultRedirect” attribute of the application’s <customErrors> configuration tag to point to a custom error page URL.

<!– Web.Config Configuration File –>

<configuration>
<system.web>
<customErrors mode=”RemoteOnly” defaultRedirect=”mycustompage.htm”/>
</system.web>
</configuration>

#################### Error End #############

We can see that error message says something about web.config file. Here is what we need to do.
1. Open IIS management console
2. Start > RUN > Inetmgr > Expand server
3. Expand the site you are getting this error on > right click > explore

Here you should be able to see a web.config file. If this web.config was recently modified by someone, please check with your team if anyone has recently modified this file, tried to deployed a farm\web application solution or run psconfig wizard on any of the SharePoint server in farm.
Note: If you have multiple SharePoint server, try the same on all the servers

In most cases, it is a web.config change done by someone from within the team which cause this issue.
If no one has done any changes:
1. Make a copy of this web.config file and open the original file. Search for “callstack” and set the value to True, again search for customerrors set it to OFF.
2. Rename the recent web.config to web.config.old with today’s date and revert the most recent web.config(date and time) file to web.config
3. Install Examdiff tool on a computer and copy the most recent web.config file and new web.config to identify the changes.

These steps will help you identify the actual cause of this error.

 

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

 

Hi Friends,

 

Today we will discuss on how to configure Multi Server Office Web Apps farm with a SharePoint farm. Also the specialty of this OWA configuration is that it can work inside and outside of firewall. Normally OWA farms are setup HTTP inside the firewall network(Internal network) and HTTPS outside the network(External world) but using this configuration we will configure HTTPS for both inside and outside network. This will not only decrease additional overhead and configuration but also is recommended by Microsoft to use HTTPS for production environment.

 

We need to meet below pre-requisites before we proceed further:
1. SharePoint farm configured and ready to use
2. Two or more Office Web Apps servers with setup files
3. One certificate for Office Web App
4. If you are using Windows server 2012 R2 then you would need to install latest update for Office Web Apps
5. FQDN name for your Office web app farm e.g.(owa.domain.com) and its DNS entry with Round Robin(You can also configure Windows NLB or a Load Balancer entry for same)

Installation of Office Web App is very simple, You just need to download the installable and execute it on all OWA servers.

Install Office Web apps on all Office Web Apps servers. If you are using Office Web App on Windows Server 2012 R2, you should install latest update for Office Web Apps. You would need an Office Web app certificate imported to IIS
Now Let’s configure Office Web App, Open Windows PowerShell and execute below command

Once the Office Web App farm is configured, open IIS and make sure SSL binding for site HTTP80 has proper certificate attached.

From IIS binding select the certificate and export the .cer file.
You need to import it to central admin manage trust.

To Attach this Office web app farm to SharePoint farm, you need to create a WOPI connection. Open SharePoint PowerShell on SharePoint server and execute below command:

New-SPWOPIBinding -ServerName “officewebapp.domain.com”

Set Wopi zone

Now if you want to add other Office Web App Server to OWA farm, you need to execute below command on existing OWA server
new-officewebappsmachine -machinetojoin “owa2server.domain.com”

Hope this will help you

Hi Friends,

Today we will discuss on how to configure Multi Server Workflow farm with SharePoint farm. Just of your information, you need to access Workflow farm only from WFE and Application servers. This means just like your database server, even workflow servers are not exposed to end users.

We need to meet below pre-requisites before we proceed further:
A. SharePoint farm configured and ready to use
B. Two or more Workflow servers with setup files
C. If you are using Windows server 2012 R2 then you would need update KB2799752(Service bus hotfix) and KB2799754(Workflow manager hotfix)
D. FQDN name for your workflow farm e.g.(Workflow.domain.com) and its DNS entry with Round Robin(You can also configure Windows NLB or a Load Balancer entry for same)

1. Let’s get started with installation of Workflow Manager 1.0 on Workflow servers. We need installable as shown below
   

2. When you will try to install the workflow.exe file you will be asked to download and install WebPlatformInstaller.exe. Now all the updates and most components are installed through WebPlatforminstaller.

 

1. Once the WebPlatforminstaller is installed, you need to search for Workflow manager and Workflow manager client and install the same.

1. Once Workflow Manager and client is installed, I would suggest you to install the updates as well.

1. Now let’s configure Workflow Server farm. This is very important so please follow steps carefully.
2. Lets execute the Workflow Manager Configuration Wizard
3. Select “Configure Workflow Manager with Custom Settings”
   

4. Now provide the SQL server instance name, Authentication, Certificate and SQL Workflow database names
   

5. You need to provide the Workflow service account credentials which will be used to connect to SQL server and for workflow IIS Application pool.
   

6. You would need to provide a Certificate Generation Key. It is just like Passphrase for your SharePoint farm
   

7. Make sure you select “Allow workflow management over http on this computer”
   

8. Along with Workflow Management, you need to configure Service Bus required by Workflow manager
   

9. Make sure you select “use the same certificate generation key as provided for workflow manager”
   

1. Once the Workflow Farm is created, you need to join other Workflow server to the farm. To do so execute the same Workflow configuration wizard and select “Join an Existing Workflow Manager Farm”
   

2. Provide the existing Workflow Farm SQL server instance name, Workflow database name and Service Bus farm database name
   

3. Provide the workflow service account and Certificate generation key used while creating workflow farm.
   

4. Select “use the same service account credentials as provided for Workflow Manager”, then select next
   

5. Once farm other server is joined to workflow farm you will see below
   

6. Once workflow is configured, you need to attach Workflow Farm to SharePoint farm. Make sure you have DNS entry(Workflow.domain.com) for your Workflow farm. If not DNS, you should at least have Host entry for same. Try to browse http://workflow.domain.com:12291 on WFE and Application server, you might see Authentication error.
   

7. Add the URL to Local Intranet and set the Local Intranet zone to “Automatically login with current username and password”
   

1. Now you should be able to browse the workflow farm details, this shows you can connect to workflow farm and it is working fine.
   

2. Now execute below command in SharePoint Powershell
   Register-SPWorkflowService -SPSite “http://sharepointsite” -workflowHostUri “http://workflow.domain.com:12291/” -AllowOauthHttp -ScopeName SharePoint –force
   

3. Now you need to activate the workflow feature on site
   Enable-SPFeature -Identity WorkflowServiceStore –Url http://sharepointsite

4. In Central Admin > Manage Service Application > Workflow Service Application Proxy
   

5. Open site in SharePoint designer – Select workflow from left pane – select new workflow
   
   Note:
   A. Workflow farm can co-locate on SharePoint servers
   B. As per Microsoft articles, for high availability you need to have at least 3 Workflow Server in farm. You cannot have 2 workflow servers in a farm. It has to be 1 or 3.

 

Hi All,

 

The most awaited SharePoint 2016 RTM launched few minutes back. It is a very important milestone for SharePoint 2016 roadmap. SharePoint 2016 is the 1st version of SharePoint which has most of Hybrid features.

 

SharePoint 16 has revealed lot of new capabilities for end users, SharePoint administrators and developers. Enhanced hybrid Service applications will bring the world closure to Office 365 and Windows Azure.

 

You can learn a lot more through SharePoint Server 2016 reviewer’s guide which has awesome use cases and lot of helpful information around SharePoint 2016. You can even download the trial version of of the SharePoint 2016 RTM.

 

One of the biggest changes in Project Server 2016 is the installation process is that Project Server 2016 runs as a service application in SharePoint Server 2016. The SharePoint Server 2016 MSI file will contain the installation files for Project Server 2016 as well, so a separate installation is no longer required as it was in previous versions of Project Server. Activating Project Server 2016 will require a PID key.

 

On May 4, 2016 there is a live online event to celebrate SharePoint 2016 share roadmap for the future of SharePoint Vnext. Jeff Teper(CVP for OneDrive and SharePoint) will share more indepth and future plans for SharePoint and OneDrive for Business for both on-premises and in the cloud with Office 365. To register your self for this event click here

 

Now few helpful resources for SharePoint Server 2016

Download the RTM Trial.
See what’s new with a demo on Microsoft Mechanics.
Download the reviewer’s guide.
Learn more about cloud hybrid search at hybrid.office.com.

 

Wish you all the best for your future with SharePoint 2016.

Hi All,

As you all know that Hybrid Delve and Search are coming to SharePoint 2016 and SharePoint 2013. Hope below additional details can be of help.

 

What is Cloud search service application?

If you plan to use Hybrid Delve and Search feature then you will have to create a Cloud Search Service Application. As far as I know key source behind Delve (Office Graph) for Delve won’t be available On Premises SharePoint.

 

How does it work?

I see a lot of concern where people ask if the crawled content would remain on Cloud server or On-premises SharePoint server. The content itself remains On-Premises and the indexed metadata is unified in a Cloud Index in Office 365. This mean crawled content resides in your environment but their index resides on Office 365 servers.

Now another concern is what happens to sensitive data which will be crawled. Its indexes would move to cloud which may not be accepted to everyone.

For sensitive content it would be recommended to not index this content using the Cloud SSA. The Combining Hybrid search approaches can use the current Query federation approach for the hybrid scenario should this need to be queried from SharePoint Online.

 

What would be an Ideal scenario if you plan to SharePoint 2016 Cloud Search Service Application?

Bill Baer says “I wouldn’t approach the new hybrid search experience as sending the entirety of your content to the unified index in SPO, just the “indexed” content, I.e. the first 100K – as related to selectively sending content to the unified index, yes, that can be achieved with the new hybrid cloud Search SA – the number of servers on-premises as related to scale-related considerations is dependent on your own throughput needs, but can be as few as a single server running either SharePoint 2013 and/or SharePoint 2016 which can serve as a proxy to legacy content sources such as SharePoint 2010. Since the index is unified in SPO and the results returned by Office 365 you can also potentially reduce the scale of your existing search architecture and let the service do the heavy lifting of storing and returning results.”

To summarize, if you have lot of content which does not contain sensitive information and your company is ready for Hybrid approach you can crawl Hugh amount of data but your search architecture would be very small because half of the load(Index and Query) would be taken by Office 365 servers. Here you will get a very good search performance even if you have single SharePoint environment.

 

What is required for Cloud search service application?

You need On-Premises SharePoint environment and Office 365 subscription to use Cloud search service application.

 

Hope this will help you with your SharePoint 2016 planning.

 

Hi All,

 

We all know SharePoint Designer 2013 is the last version of SharePoint Designer available to us. Now another big hit is SharePoint Foundation 2013 is also the last free version of SharePoint product available with us.

 

I just got confirmation that Microsoft would not release SharePoint Foundation 2016 along with SharePoint Server 2016. This is a big hit to companies who use SharePoint foundation in their current organization and planned to upgrade to SharePoint Foundation 2016. I very well know that a very big SharePoint market uses SharePoint Foundation because it is free and it has great features.

 

If you use SharePoint Foundation and you want Microsoft to continue SharePoint Foundation product, you can tweet @williambaer or email him at [email protected]. That’s your only chance where you need to show Microsoft how you use SharePoint foundation, how does it benefit you and why Microsoft should continue this product line

 

Hope this will help you with your SharePoint 2016 planning.

Hi All,

I was recently asked if we have any limit for Query text we use to perform search in SharePoint.

After some research I found that the length limit of a KQL query varies depending on how you create it. If you create the KQL query by using the default SharePoint search front end, the length limit is 2,048 characters. However, KQL queries you create programmatically by using the Query object model have a default length limit of 4,096 characters. You can increase this limit up to 20,480 characters by using the MaxKeywordQueryTextLength property or the DiscoveryMaxKeywordQueryTextLength property (for eDiscovery).

Again the length of FAST Query Language queries is limited to 2,048 characters.

This applies to SharePoint 2010, 2013

Reference : https://msdn.microsoft.com/en-us/library/office/ee558911.aspx

Note: You cannot modify this value in Office 365 SharePoint site