What’s New in SharePoint 2016

1) Hybrid

Microsoft has worked hard to bridge the gap between SharePoint Online and SharePoint On-Premises. Some businesses trust the cloud, while others, for privacy concerns, would rather keep their data on-premises, since they can’t always trust servers to host all their sensitive information.

SharePoint 2016 offers a hybrid feature that allows for the storage of data both on the cloud and on premises. The hybrid installations are now simplified and automated.

2) Hybrid Search

This is possibly the biggest new addition to SharePoint 2016.

The hybrid search offers a unified search experience that runs across SharePoint Online and SharePoint On-Premises for your end users.

Previously, the hybrid setup showed different result lists for SharePoint On-Premises and SharePoint Online on one page, but the results were never organized. Now, you can index all your data and specify what kind of content you would like to search for.

3) Media Preview

SharePoint 2016 also allows you to preview videos and images while hovering over them with your mouse, so you no longer have to click on content to view it.

4) Large Files

Older versions of SharePoint do not support large files; any file larger than 2047 MB will not be uploaded. With the release of SharePoint 2016, the permitted file size has been increased to 10 GB.

However, it’s generally best to avoid storing very large files in SharePoint, as you may get disconnected while uploading them.

5) Complete Privacy

Hacking is a big issue nowadays for companies with sensitive information. With this in mind, Microsoft decided to focus on improving its encryption connections in SharePoint 2016.

SharePoint now supports Transport Layer Security (TLS 1.2), which ensures a greater degree of privacy and data encryption between two communicating apps.

6) Mobile Experience

Accessing SharePoint on a mobile device used to be a nightmare for many due to its lack of responsive design. Fortunately, SharePoint 2016 comes with a user-friendly mobile version featuring excellent design and navigation. Now, you can access SharePoint from anywhere and speak with your team remotely to get work done more easily.

7) Server Roles

The release of SharePoint 2016 came with server role configuration, a feature that allows a SharePoint administrator to assign the role of their choice to a specific SharePoint 2016 server. This enables only the functionalities that you need and ensures that all servers belonging to each role are cooperative. You can also convert servers to serve new roles if needed.

8) Faster Site Creation

SharePoint 2013 used to take over 40 seconds to create a site. With PowerShell configurations, you can now use templates to create site collections within a few seconds, generally improving site performance.

9) Compliance Centre

This feature is essential for controlling the flow of data exposed to the cloud. SharePoint allows you to create your own policies and apply them as needed to your environment.

For example, it offers a feature similar to a retention policy; after a certain number of years, you can delete information from OneDrive for Business sites.

10) App Launcher and Sites in One Place

SharePoint 2016 allows you to view both On-Premises and Office 365 in one location via the App Launcher under the “Sites” app.

The App Launcher provides easy access to Office 365 apps such as Delve, OneDrive, OneNote, and more.

11) Durable Links

Lastly, the links you distribute will remain intact even after a document moves to another location or is renamed.

You can achieve this by using a Resource-ID-based link for documents hosted in SharePoint. You no longer have to search files by name and can just use the resource ID containing the document stored in the database.

These are just a few of the great features Microsoft introduced in SharePoint 2016. Do you have any others you’d like to add? Let us know in the comments.

Advertisements

Windows 10 Hyper-V Property "MaxInternalSize" does not exist in class "Msvm_VirtualHardDiskSettingData"

Be sure you have a good backup before trying any of these steps. They worked for me and the problem I was experiencing – DO NOT use these instructions for any problems other than the one described here.

If you mounted one of your VM’s VHDs and then, after un-mounting it, tried to start it on Windows 10 you will get the error message that the VM failed to change state.

If you attempt to inspect the virtual disk in Hyper-V (or from the Virtual Machine Settings), you will get this error message:


There was a problem with one of the command line parameters. Either ‘YourMachineNameHere’ could not be found, or ‘YourVMDiskPathHere’ is not a valid path.
Property ‘MaxInternalSize’ does not exist in class ‘Msvm_VirtualHardDiskSettingData’.

The solution is to use PowerShell to relink the checkpoint differencing disk with the parent VHD.

First, if you have multiple checkpoints, find out which checkpoint disk (AVHDX) points to the parent VHDX file instead of another AVHDX checkpoint differencing disk.

The simplest way to do this for a small number of snapshots is to use the PowerShell command Get-VHD to list the parent disk for each AVHDX file.

Example output:

PS D:\vms\Windows 7 32 SP1\Virtual Hard Disks> get-vhd '.\Windows 7 32 SP1_14285
771-A2EC-4596-8ED3-2AA162EC280D.avhdx'
ComputerName            : DELL-XPS8700
Path                    : d:\vms\windows 7 32 sp1\virtual hard disks\windows 7
32 sp1_14285771-a2ec-4596-8ed3-2aa162ec280d.avhdx
VhdFormat               : VHDX
VhdType                 : Differencing
FileSize                : 4194304
Size                    : 68719476736
MinimumSize             : 68719476736
LogicalSectorSize       : 512
PhysicalSectorSize      : 4096
BlockSize               : 2097152
ParentPath              : D:\VMs\Windows 7 32 SP1\Virtual Hard Disks\Windows 7
32 SP1.vhdx
DiskIdentifier          : B46EE6F1-46D6-4ED0-BEE8-343509B48C75
FragmentationPercentage :
Alignment               : 1
Attached                : False
DiskNumber              :
Number                  :
So we can see that this is our desired snapshot since ParentPath points to our VHDX file. Read more about Get-VHD here: PowerShell Get-VDH
Next, use Set-VHD to set exactly the same parent disk as we found above.

PS C:\WINDOWS\system32> set-vhd 'd:\vms\windows 7 32 sp1\virtual hard disks\windows 7
32 sp1_14285771-a2ec-4596-8ed3-2aa162ec280d.avhdx' -ParentPath
"D:\VMs\Windows 7 32 SP1\Virtual Hard Disks\Windows 7
32 SP1.vhdx"
-IgnoreIDMismatch
If the Ignore ID Mismatch option is not used, you will get the error:

Failed to set new parent for the virtual disk.
There exists ID mismatch between the differencing virtual hard disk and the
parent disk.
Read more about Set-VHD here: PowerShell Set-VHD
Courtsey : https://thatonecomputerguy.wordpress.com/2016/03/18/windows-10-hyper-v-property-maxinternalsize-does-not-exist-in-class-msvm_virtualharddisksettingdata/

Top 10 SharePoint 2010 Configuration Mistakes — and How to Fix Them

Microsoft SharePoint 2010 is a complicated beast, with more knobs and levels than you can shake a stick at. It’s no wonder we get some of them wrong from time to time. Over the past year and a half of installing SharePoint 2010, I’ve seen quite a few configuration mistakes, mostly at my own hands. In this article, I’ll cover 10 of these errors. I’ll explain what the correct configuration is, why it’s correct, and how to correct the setting in your farm. If you make all the changes in this article, you’ll have the beginnings of a beautiful farm — and one less likely to be ridiculed by your friends and neighbors.

Mistake #1: Scrimping on SharePoint’s RAM or Hard Disk Space

If I’ve seen it once, I’ve seen it a hundred times: a poor, defenseless SharePoint server working as hard as it can to keep users happy, but having its hands tied because of limited resources. This situation is usually a casualty of aggressive virtualization. Virtualization itself isn’t bad, but it must be done intelligently and without sacrificing SharePoint’s ability to do its job.
If SharePoint finds itself starved for RAM, it starts shutting off functionality so that it can fit into the available space. It also caches less in the web application pools and recycles those pools more often. Less caching and more recycles result in a degraded end-user experience, as SharePoint must compile the same ASP.NET code over and over. And no one likes unhappy users, not even their mothers.
The solution to this particular issue is easy: Add RAM. Microsoft has published the hardware requirements for SharePoint 2010 in the TechNet article “Hardware and software requirements (SharePoint Server 2010).”  These requirements state that at the very least, each SharePoint 2010 production server should have 8GB of RAM and a C drive with at least 80GB. In many cases, that won’t be enough. If your servers are in production, you can watch their memory utilization to see whether they use the entire 8GB of RAM. If so, they could use more. If your servers are not yet in production, you can use a variety of load-testing tools to simulate your intended load and see how the servers hold up. For example, you can download the Microsoft Load Testing Kit, part of the SharePoint Administration Toolkit.
As for your C drive, SharePoint itself doesn’t need much space, but Windows does. After all, your server has several years of Windows patches to look forward to. While you’re adding drive space to your machine, consider adding a secondary drive as well. This drive is a great place to store all the files that you use when you install SharePoint. All the third-party installation files can go there too. You can also have SharePoint put its log and Search index files on this drive. This approach takes some pressure off the C drive. Happy C drive and happy end users equal a happy SharePoint server administrator.

Mistake #2: Using Virtualized Microsoft SQL Server

As I said in mistake #1, virtualization isn’t bad. But virtualization allows administrators to make mistakes on a much grander scale. Take virtualizing SQL Server. In the context of SharePoint, this process can be especially painful. The main mistake I see when virtualizing SQL Server is overcommitting the host, be it through RAM, CPU, or drive space. Because everything in SharePoint is stored in SQL Server, if SQL Server is slow, SharePoint is slow.
The obvious solution is to move SQL Server to a physical box, on which it doesn’t need to share resources. Moving SharePoint’s SQL Server instance is easy, thanks to aliases. I’ve outlined this process, with pictures, at www.toddklindt.com/sqlalias.
If you can’t get a physical SQL Server box, then at the very least ensure that your virtualized SQL Server instance has a fighting chance. First, make sure that its virtual drives aren’t thin provisioned. I/O is one of the areas in which virtualized SQL Server struggles the most, and thin-provisioned drives exacerbate that problem. Also try to put the SQL Server guests’ virtual drives on their own spindles on the host. Doing so should improve I/O by preventing SQL Server from fighting other guests for time with the drives. Finally, you shouldn’t allow the virtualization host to overcommit its RAM. If the host must swap to meet its RAM obligations, then it’s slowing down SQL Server.
Brent Ozar has recorded a brilliant video on how best to virtualize SQL. Go get some wine and pizza, invite your fellow SharePoint admins, dim the lights, and watch that video. You’ll learn a lot.

 

Mistake #3: Using the Farm Configuration Wizard

Using the Farm Configuration Wizard was a pretty common mistake when SharePoint 2010 first came out but thankfully has diminished as our familiarization with SharePoint 2010 has increased. The wizard’s list of atrocities is long, so I’ll just cover some of the better known ones. First, and maybe most heinous, is that all the databases that the wizard creates have nasty globally unique identifiers (GUIDs) at the end of their names. The wizard also creates a content web app, at http://servername, that just doesn’t scale well. To add insult to injury, the wizard creates your My Site host on that same web app, at http://servername/my. Finally, the wizard encourages you to create service applications that you might not actually use. It’s tough to resist the siren song of those check boxes, I know.
The Farm Configuration wizard leaves its dirty handprints all over SharePoint, and it can be a challenge to clean up all of them. However, a few places can be easily fixed. Start with your web apps. Create a web app for My Site and give it a Fully Qualified Domain Name (FQDN), such as mysites.company.com. Create a My Site host at the web app’s root. Use the Windows PowerShell cmdlet Move-SPSite to move any My Site to one content database, and then attach that content database to your new web app. You’ll also need to adjust your User Profile Service and tell it about your new My Site location.
Next, clean up your service applications. Go through your list of service applications and delete any that you aren’t using. You gain no benefit from having a service application that you aren’t going to use for another six months. After you’ve deleted unnecessary service applications, stop the associated service instances (also called services on server) that power them. If possible, remove the GUIDs from the service application database names. The technique for completing these tasks varies among service application; the Microsoft article “Rename or Move Service Application Databases (SharePoint Server 2010)”  has directions for all the service applications. Of course, take good backups before doing any of this.

Mistake #4: Using an Incorrect URL when Creating a Content Web App

Like any relationship, SharePoint and Microsoft IIS have communication problems from time to time. Web app creation is one of those times. SharePoint doesn’t tell IIS about changes that you might make to a web app after it is created. For instance, if you create an Alternate Access Mapping (AAM) for a web app in Central Administration, you still need to go into IIS and add the host header for the new address.
The issue is compounded when SharePoint farms that you never thought would need to be accessible from the Internet suddenly need to be accessible from the Internet. Budding SharePoint administrators commonly give their web apps short URLs, such as http://portal, to save users some typing. Of course, that URL doesn’t route across the Internet, so the web app needs a fully qualified URL added to its stable of AAMs. Not only is this new URL not written to the IIS host headers, but it’s also missing from all the alerts, workflows, and anything else that saves URLs — all those items have the old URL hard-coded in. Because SharePoint didn’t write any additional URLs to IIS when they were created, it won’t write them to any new SharePoint servers that are added to the farm. Nor will SharePoint write these changes to IIS if the Microsoft SharePoint Foundation Web Application service instance is stopped and started.
This issue might not seem like a big deal, but it has bitten many people at the worst possible time: during an outage. In a few cases, administrators have lost or needed to rebuild a SharePoint server and forgotten about the host headers that they put in manually months earlier. SharePoint is up and going, but when browsing to SharePoint, end users get the blue IIS 7 splash page instead of the SharePoint page that they were expecting. Again, unhappy users usually mean unhappy administrators.
Because SharePoint writes host headers only when a web app is created, you can’t fixproblematic web apps. You’ll need to recreate them. That’s good news and bad news. The good news is that you won’t lose any of the content that your users worked so hard to create. The bad news is that you will lose all the settings that you worked so hard to create.
The first step is to make notes of all your web app settings. In most cases, there won’t be many, and you’ll be familiar with any changes that you made. Then, detach the content databases from your web app. Keep them safe; you’re going to need them. Next, make a copy of the web.config file for that web application. Some settings, such as forms-based authentication (FBA) and BLOB cache settings, are in that file. Finally, go into Central Administration and delete the web app. Tell SharePoint to delete the extra stuff. The scary part is over.
Now, recreate the web app, but do it right this time. First, enter the correct, fully qualified URL in the Host Header box. Do your end users a favor, and put the web app on port 80, as Figure 1 shows. Under the Security Configuration settings, accept all the defaults, even if you’re going to use Kerberos or SSL. You can change those settings later, and you want to make sure that the web app works correctly before you apply fancy security settings. Doing so helps in any troubleshooting that you might need to do. Under the Application Pool settings, pick an existing application pool. (I’ll explain why in the next section.)
Figure 1: Creating a new web app

Figure 1: Creating a new web app

 

It is important to give your content databases distinct names. You should be able to look at a content database name and know exactly which web app that database goes with. This is another one of those things that doesn’t usually seem important but is priceless in a disaster-recovery situation. If the content databases that you detached from the web app before you deleted it didn’t have such names, then take this opportunity to right that wrong when you recreate the web app. Give the new content database a good name, then use the PowerShell cmdlet Move-SPSite to move the site collections to that new database. If your content database already has a good name, enter it during the creation of the new web app. If you had multiple content databases, attach the rest after the web app is created.
After the web app is created, you can tweak settings as needed. Most settings can be changed in Central Administration. If you made any changes to the web.config file of the original web app, now is the time to copy those changes to the newly created web.config file. You can use a program such as Notepad++  to compare the two files. You should now have a well-created web application that you can trust in times of crisis.

Mistake #5: Running Web Apps or Service Apps in Separate App Pools

Web apps and service applications run inside of an application pool, which is a W3WP.exe process that runs on your server. Unless you have reason to do otherwise, you should run all SharePoint web apps inside one application pool; the same goes for the service applications. Running each web app in its own application pool makes inefficient use of the server’s memory. Each application pool has a minimum overhead of more than 100MB, and its memory footprint increases as it caches content that’s rendered frequently. Figure 2 shows multiple W3WP.exe processes running as sp_webapps, the result of web apps running in separate application pools. We’ve all experienced SharePoint slowing first thing in the morning because the app pools recycle overnight and need to warm up and cache that content again. Well, multiple application pools mean that the same content is cached multiple times. Most users are impatient. I’m sure that studies would show that they spend the time waiting for SharePoint to respond by thinking of ways to punish us for SharePoint’s poor performance.
Figure 2: Result of running web apps in separate application pools

Figure 2: Result of running web apps in separate application pools

For service applications, this problem is easy to fix. First, make sure that you have a good service application pool to use. I recommend calling this pool Default SharePoint Service App Pool so that it floats to the top of all your drop-down lists. Use a dedicated sp_serviceapps account for the pool’s identity. Most service applications allow you to assign them to a new service application pool by modifying their properties in Central Administration. If the option is unavailable there, look for it in PowerShell.
Web applications are a tougher matter. There’s no easy, out-of-the-box way to change the application pool that a web app is using. Fortunately, we have PowerShell at our disposal. The steps to this process won’t fit in this article, but I outline them in detail in the article “How to change the App Pool ID of a SharePoint 2010 Web Application.” 

Mistake #6: Using One Account for Everything

Security is complicated, and SharePoint doesn’t necessarily make it any easier. Using just one account — maybe even the coveted Domain Administrator account — is so easy. We’ve all done it, even though it’s a bad idea. When you use an existing account, you open up SharePoint to several security issues. Anyone who knows the account password can do anything in SharePoint, so you can’t separate duties. You also lose the ability to audit who made which changes. And if that common account password is compromised or needs to be changed, you jeopardize SharePoint’s uptime as well. Even if you use one dedicated account for SharePoint, you leave yourself vulnerable to attack. If that account is compromised via a security exploit, the bad guys will have access to everything in SharePoint.
To fix this mistake, start by creating the accounts that I outline in this blog post . Add the sp_webapps and sp_serviceapps accounts as managed accounts. Use the techniques that I describe in Mistake #5 to fix your web app and service application accounts. You can change the default content access account for the Search service application at the Search Service Application page. Under Central Administration, Security, Configure Service Accounts, you can change the accounts that other processes use as well. (You can even change the Farm Account there. I’ve done so in test environments but haven’t been brave enough to do it in production.) If you’re using the User Profile Service, make sure that your new sp_userprofile account has the correct permissions in Active Directory (AD), and recreate your AD connection in the User Profile Service.
You can also use the steps that I describe in “How to create a SharePoint 2010 admin account and stop using sp_farm” to give an account the correct permissions to administrate SharePoint, without needing to use another highly privileged account.

 

 

Mistake # 7: Keeping Default SharePoint Database Settings

When SharePoint creates its multitudes of databases, it makes some bad assumptions. Take the autogrow settings: The database files grow by 1MB at a chunk, almost ensuring that they’re going to autogrow with every upload. Not only does this slow down SQL Server (which slows down SharePoint), but it also results in database files that are spread all over your drives in itty-bitty 1MB chunks.
SharePoint also creates most of its databases, notably the Config and Content databases, with the recovery model set to Full. Although this is great if you want to recover data, you must manage the process correctly or those sneaky .ldf files will slowly, methodically fill your hard disk. If you think users get upset when SharePoint is slow because of fragmented databases, you should see how angry they get when SharePoint stops completely because the SQL Server drives are full.
To fix this mistake, set your databases’ autogrow settings in such a way that they don’t need to grow frequently. For most farms, I recommend changing the 1MB autogrow to something like 500MB or 1GB. Autogrow should also be a last resort. Someone, either the SharePoint administrator or a dedicated DBA, should pregrow your databases so that autogrow is unnecessary.
Your recovery model setting needs to be consistent with your disaster recovery plans. If you need your transaction logs, make sure you’re performing routine log backups to keep those .ldf files in check. If you don’t need your transaction logs, then consider switching your databases to the simple recovery model. Doing so will keep your .ldf files from swelling up like a nasty bee sting.

Mistake #8: Not Enabling BLOB Caching

I don’t know about you, but I’ve never heard an end user say, “SharePoint is too fast. Could you get it to respond a bit more slowly?” We all want SharePoint to get files to the users as quickly as possible. However, more often than not, I see SharePoint farms without BLOB caching enabled. BLOB caching is one of the easiest and least expensive ways to improve SharePoint performance. Not only does it help to get files to users more quickly, but it also eases the burden on SQL Server. Everybody wins.
This might be the easiest solution so far: Enable BLOB caching, of course! BLOB caching is actually a function of IIS; SharePoint just takes advantage of it. Therefore, to enable BLOB caching requires a change to each web app’s web.config file on each server. Fortunately, the setting already exists and just needs to be enabled. By default, the web.config files are in a directory under C:\inetpub\wwwroot\wss\virtualdirectories. Each web app has a directory and a web.config file. Open one of these files and look for the following line:
<blobcache enabled="false" location="C:\blobcache\14" maxsize="10" path="\.(gif|jpg|jpeg|jpe|jfif|
bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|
mpeg|mpg|rm|rmvb|wma|wmv)$”>
To enable BLOB caching, replace “false” with “true” and save the web.config file. You should also move the file to a directory on a drive other than the C drive. The maxSize parameter is measured in gigabytes, with a default of 10GB. If the space is available, you might want to increase this size.
If editing this file in Notepad on all your servers isn’t your idea of fun, you can use PowerShell to automate the process. You still need to perform the process on each server, but using PowerShell is quicker and reduces the chances of a mistake. To begin, download the script and save it to a file named blobcache.ps1. This script contains two functions: Enable-SPBlobCache and Disable-SPBlobCache. Each function takes a web app from the pipeline and enables or disables BLOB caching on that app. The code to enable BLOB caching on each web application in the farm looks like this:
                              PS E:\Install\Scripts> . .\blobcache.ps1                              PS E:\Install\Scripts> Get-SPWebApplication | Enable-SPBlobCache 

Mistake #9: Not Installing a PDF iFilter

Most organizations have a tremendous number of PDF files in their SharePoint farms, and those files represent a wealth of information. End users want to be able to discover that information by using SharePoint Search. Getting users excited about SharePoint Search is a great way to get them excited about SharePoint in general.
Installing a PDF iFilter is fairly easy. Adobe has a free PDF iFilter that you can install. You can find the download link and detailed installation instructions in the Microsoft article “SharePoint 2010 – Configuring Adobe PDF iFilter 9 for 64-bit platforms.” You need to install the iFilter only on those SharePoint servers that run the Search Index role, although installing it on the rest of your SharePoint servers doesn’t hurt. If you have a large farm and want to reduce the time needed to index your PDF files, you can use thePDF iFilter from Foxit. This product has better performance than the Adobe iFilter but isn’t free.

 

 

Again, you can harness PowerShell to make this task easier. Brian Lalancette, creator ofAutoSPInstaller, wrote a great script that automatically downloads, installs, and configures a PDF iFilter, and this script has become my preferred method. The script is part of a larger package, so I’ve stripped out the relevant parts and posted them on this page.  Save that file as pdfsearch.ps1. The file contains two functions: Configure-PDFSearch and Configure-PDFIcon. The former installs and configures the iFilter; the latter adds a PDF icon to the SharePoint interface. As I describe for the script in Mistake #8, install the functions by dot-sourcing the pdfsearch.ps1 file and then executing the function.

Mistake #10: Not Pointing Your SharePoint Servers at Themselves

When SharePoint works, it is magnificent. When it doesn’t work, it can be a nightmare to fix. For this reason, anything you can do to ease troubleshooting is time well spent. To that end, I make sure that every server in the SharePoint farm points to itself for all web apps. If I get sporadic reports about SharePoint not responding, I can easily use RDP to log in to each server and try to pull up SharePoint. If this attempt works, then I know that the server is working. If SharePoint does not come up, then I know in exactly which Microsoft User Location Server (ULS) logs to look for the relevant errors. No worrying about which web front end the load balancer sent my request to. The quicker you get to the correct log files, the quicker the problem is resolved.
Pointing your Search indexer at itself has another advantage: It improves performance for your end users. If you don’t point your Search server at itself, then when it starts to perform a crawl, it lets DNS do its work and then starts crawling whichever web front end DNS points it to. That server is most likely the same one that is sending pages to your end users. Making the server do double-duty means that everyone waits longer. Pointing the Search server at itself means that your web front end doesn’t need to handle that traffic and can get back to doing its #1 job: keeping users happy.
There is a simple fix for this mistake: Open the hosts file (C:\windows\system32\drivers\etc\hosts) on each SharePoint box, and add all the URLs that SharePoint knows about. Point those URLs to 127.0.0.1, which translates to “this computer.” Figure 3 shows how this file looks in a typical SharePoint environment. This approach provides all the benefits that I’ve mentioned but uncovers a nasty beast: loopback detection. This monster, as well as how to defeat it, is scary and too long for this article, but you can read all about it in my blog post “Can’t crawl web apps you KNOW you should be able to crawl.” 
Figure 3: Hosts file in a common SharePoint environment

Figure 3: Hosts file in a common SharePoint environment

As you might have noticed, I’m a fan of using PowerShell to fix these mistakes, and #10 is no different. This script will automatically add all SharePoint’s URLs to your server’s local hosts file and fix the loopback detection beast in one fell swoop. Is there anything PowerShell can’t do?

Everybody Makes Mistakes

There are as many ways to screw up SharePoint as there are grains of sand on the beach. I ought to know; I think I’ve made them all. Twice. Although you might witness (or make) one or two of the mistakes in this article, the good news is that they can all be fixed. Just follow the instructions here, and your SharePoint farm will be tip-top in no time.
Reference: http://sharepointpromag.com/sharepoint-2010/top-10-sharepoint-2010-configuration-mistakes-and-how-fix-them

Web Designer Galleries section is missing on SharePoint Online

Problem

Recently I had to create a trial Office 365 account for a demo purposes. But there are some sections such as “Web Designer Galleries”, “HTML Field Security”, “SharePoint Designer Settings” (under Site Collection Administration section) were missing on the setting page of the SharePoint site.
Also I was not able to upload JavaScript file in my document libraries.
So here are the steps for resolving the issue.

Solutions

Method 01
Step 01: Go to Admin panel
image
Step 02: Go to SharePoint admin center by selecting SharePoint from the left navigation
 001Step 03:  There go to the setting page
002Step 04: From there allow Custom Script
image
There is a  note saying “changes to this setting might take up to 24 hours to take effect.” So here is the power shell command to do that for immediate effect.
Method 02
Step 01: Open the SharePoint Management shell
Step 02: Type the below command to connect with SharePoint Admin Center in management shell. You have to replace your admin center url which is in line 1.

  1. $spadminurl = https://suhailj-admin.sharepoint.com/&#8221;
  2. connect-sposervice -url $spadminurl

Step 03: You will be asked to enter user name and password.
image
Step 04: Enter the below commands. You have to mention your site collection url where you need the sections.

  1. $spsiteurl = https://suhailj.sharepoint.com&#8221;
  2. Set-SPOsite $spsiteurl -DenyAddAndCustomizePages 0

 

Conclusion

Immediately you can see the web designer galleries in setting page; and I was able to upload JavaScript files in my document libraries.
image

SharePoint 2013: Optimize your development Environment

SharePoint 2013 demands more resources – especially more memory. When we need to setup a SharePoint 2013 environment we can optimize resource usage in the development server by provisioning/configuring required services as well as following some other guidelines listed in this post.

Search Service Applications

Search Service is EXTREMELY resource hungry. noderunner process (Search Service process for crawling/indexing) is widely known for it’s resources usage footprint. In case you don’t need search service in your development server, you can delete the service application or at least stop the service. If you need to use the search service from time to time, you can keep the search service application running but stop the search service. However, if you try to stop the search service from windows service, you will find the service will be started again by SharePoint. The correct way to stopping service is from Central admin as shown below:

image

If you need the search service components (crawling/indexing) on development server, you can reduce the performance level by running the following command in SharePoint PowerShell. More information available at http://technet.microsoft.com/en-us/library/ff608126.aspx.

Set-SPEnterpriseSearchService -PerformanceLevel Reduced

You can also control the noderunner memory consumption by changing ‘memoryLimitMegabytes’ in the config file “C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config”. Please remember, changing the value to too low might cause the search service to fail.

Provision Required Service Applications only

If you install SharePoint using Installation wizard, different service applications are installed but you many not need all of these service applications. From Central admin you can delete unnecessary Service applications as well as stop services. As you can see below

Stop unnecessary Web Application

Even web application running in your development environment will create w3wp process (if a separate application pool is used) or at least use resources. So if you don’t nee a web application for time being, you can stop the web application as well as related application pool from IIS Manager.

Visual Studio IntelliTrace

If you use Visual Studio debugging in the server and your Visual Studio supports IntelliTrace and the feature is enabled, you can disable the option. That might improve your debugging experience. More information on how to enable/disable the feature can be found at: http://msdn.microsoft.com/en-us/library/dd264948(v=vs.100).aspx

Multiple Disk Drive

If you have configured multi-server farm, you can keep some servers in another disk drive. For example, I’ve a multi-server (4 servers – AD, SQL, WFE and App) farm and I’ve kept two servers in my external USB3 supported external drive. So rather than four server vying for the same disk access, two are vying for internal disk access and other two are vying for external disk.

Even if are running a single server farm, you can use an external SSD drive (or USB3) for better I/O throughput. Especially if you can move your database files in an external drive, you will experience much better performance.

Tracing Service

SharePoint uses a windows Service ‘SharePoint Tracing Service’ for logging. sometimes, like during deployment, you will find the log file is growing few hundreds megabytes in short time. So tracing service might take a bit role in performance. If you don’t need the log file for a period of time, you can disable the windows service. During development I usually disable the service and when I need to see the log file, I enable the service.

Using SharePoint’s Rich Text Box in a page

ASP.Net does not provide a rich text box control in its set of web controls. So, if you need to place a rich text box on your SharePoint page you’ll have to use a commercial, free or open source text box control (and there are plenty out there). However if you don’t want to introduce another dependency, in the form of an external control, you can use SharePoint’s built-in rich text box.
If you’re creating a page layout that binds to a content types field then its straight forward and you can useRichTextField class. However, if you want to display a textbox that does not interact with a content type then you can use the InputFormTextBox and configure its properties so it render as a rich text box.
Here is an example:
Note: change the RichTextMode value to ‘FullHtml’ to render more html icons in text box’s tool bar.

5 Ways to brand Office 365 without Modifying the Master Page

Starting from 1 easiest to 5 hardest (requires dev skills)

1. Office 365 (Personal and Tenant Wide) Themes – You should start here.

Office 365 themes
After you’ve created your theme
  • Custom logo optionally clickable: Select the image and upload your own JPG, PNG, or GIF with a resolution of 200 x 50 pixels, no larger than 10 KB. This appears in the top navigation bar on every page.
  • Top Nav Background image: Your own JPG, PNG, or GIF, no larger than 15 KB. The background image appears in the top navigation bar on every page.
  • Prevent users from overriding theme: Option to enforce theming at the user level so that everyone in the organization sees the theme you create. The exception to this is a high contrast theme used for accessibility purposes.
  • Accent color: Select a color to use for the app launcher icon, mouse over color, and other accents.
  • Nav bar background color: Select a color to use for the background of the navigation bar. Appears at the top on every page.
  • Text and icons: Color to use for the text and icons in the top navigation bar.
  • App menu icon: Color to use for the app launcher icon
You’ll see your new theme on the Office 365 admin center right away and after a short delay, you’ll see it throughout Office 365 including Outlook and SharePoint pages. You can remove your custom icon or custom colors at any time. Just return to the theme page and choose Remove custom theming or Remove custom colors.
IMPORTANT: In addition to customizing your theme, you can add custom tiles to the My Apps page and then add them to the app launcher or add them to the navigation bar.
Office 365 Branding goes beyond SharePoint
When considering any a custom UI for SharePoint, always consider other services such as One Drive, User Profiles, and Delve. Any CSS, JS, or master-page customization applied to SharePoint as these will not automatically propagate across these other workloads. The only shared tool at this point is the top suite bar. Fortunately, this for the most part is customized by using Office 365 themes. Themes are limited, but this is where you should start. Outlook does have some personal theming, but shouldn’t need much branding anyway. For email you could use Outlook.com add-ins, and recommend company signatures for consistency.
Refrence link : https://support.office.com/en-us/article/Customize-the-Office-365-theme-for-your-organization-8275da91-7a48-4591-94ab-3123a3f79530?ui=en-US&rs=en-US&ad=US
2) Office 365 site options: SharePoint Site Look and Feel branding “Change the Look”
Another good place to start with changing the look of your site while clearly staying way within boundaries is with the Look and Feel section of site settings.
Add a site title, pick a logo, add simple base colors. I would avoid doing too much here or your site will look like it came from FrontPage 98. The out of the box theming engine of composed looks are actually quite ugly in my opinion, but the ability to customize these is in the SharePoint UI and very easy to do. Site themes and composed looks are well covered on the web. The “Change the look option” site theme has skins and additional colors. Changing the navigation is simple and this also is benign and expected. 
3)  Provisioning template in PnP Partner Pack for responsive UI for Office 365 SharePoint Online
Alternative CSS is much more lightweight, but still will require testing and maintenance. Join the Office Dev PnP community where you can share code and best practices. First, use alternative CSS instead of adding references to files on your master pages. You can test in our browser by changing the browser size, but ultimately need to test. A good practice is having a couple of tenants… one in early adopter with a handful of test users and the other in the normal adoption rate.

4) Office UI Fabric
Office UI Fabric is a responsive, mobile-first, front-end framework for developers, designed to make it simple to quickly create web experiences using the Office Design Language. The framework is used internally on products within Office 365—such as our suite branding, OneDrive.com, Outlook.com, Delve and the Video Portal. With Office UI Fabric you can apply simple CSS styles to make your web applications look and feel like the rest of Office. The styling takes into account typography, color, icons, animations, responsive grid layouts and localization.
5)Use JavaScript Injection to embed custom scripts and/or third-party libraries into your sites
“You can use the Office 365 JavaScript UI controls to add an Office 365-style navigation bar to your app and also let users access data about people in Azure Active Directory (AAD). These JavaScript UI controls do not require server-side code, and can be integrated into a single-page application (SPA) with just a few lines of code.”
The Office 365 JavaScript UI controls are supported by the following web browsers:
  • Internet Explorer 10+
  • Chrome 43+
  • Firefox 39+

Renew an expiring client secret in a SharePoint Provider Hosted Apps (Add-in) without deploying the Apps again by changing Client Secret key using Powershell

When you create Provider Hosted you have registered a Client ID and Secret ID using SharePoint Register App Page (AppRegNew.aspx) and you have used this Client ID and Secret ID in the Web Config in the web application part of the provider hosted app (App Web), after one year your Apps is stop working, and you will get the following Error:
System.IdentityModel.Tokens.SecurityTokenException: Invalid JWT token. Could not resolve issuer token.
Why?
By default the Secret Key will expire after one year, unfortunately you will not get any alerts before the expiry date, you have to renew the Secret Key at least one day before its expiry, because the new key will take about 12 hours to be generated, following steps will renew the Secret ID
      1.       Use online power shell to create new Client Secret ID
Download the Power shell for Office36:

  •          Microsoft Online Services Sign-In Assistant is installed on the development computer.
  •          Microsoft Online Services PowerShell Module (32-bit; 64-bit) is installed on the development computer.
  •      You are a tenant administrator for the Office 365 tenant (or a farm administrator on the farm) where the app was registered with the AppRegNew.aspx page.
        After downloading the powershell open it and connect to SharePoint online using following     CMDLET:
        Connect-MsolService
        A popup will ask for Username and Password type your Username as:     UserName@DomainName.com
    2.       Find out the expiration dates of the apps for SharePoint installed to the Office 365 tenancy
Get-MsolServicePrincipal  |Where-Object -FilterScript { ($_.DisplayName -notlike “*Microsoft*”) -and ($_.DisplayName -notlike “autohost*”) -and  ($_.ServicePrincipalNames -notlike “*localhost*”) } | foreach-object{
    $principalId = $_.AppPrincipalId
    $principalName = $_.DisplayName

    Get-MsolServicePrincipalCredential -AppPrincipalId $principalId -ReturnKeyValues $true | Where-Object { ($_.Type -ne “Other”) -and ($_.Type -ne “Asymmetric”) } |  foreach-object{
        $date = $_.EndDate.ToShortDateString()
        write-output “$($principalName);$($principalId);$($_.KeyId);$($_.type);$($date);$($_.Usage);$($_.Value)”
    }
} > c:\temp\appsec.txt

    3.       Generate a new secret
$clientId = ‘SPECIFY YOUR CLIENT ID HERE’
$bytes = New-Object Byte[] 32
$rand = [System.Security.Cryptography.RandomNumberGenerator]::Create()
$rand.GetBytes($bytes)
$newClientSecret = [System.Convert]::ToBase64String($bytes)
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Password -Usage Verify -Value $newClientSecret
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Symmetric -Usage Sign -Value $newClientSecret
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Symmetric -Usage Verify -Value $newClientSecret
$newClientSecret
Copy the new Secret to use it as mentioned in the next Section
    4.       Update the web Config of the Azure Apps Web with the new Secret
The good news is that it’s not required to deploy the Apps again, you just you need to updated the web config file of the web application part of the provider Hosted App (App Web)
    <add key=ClientId value=c86eb4d4-0efd-4269-92ba-97fd48689ec5 />
    <add key=ClientSecret value=“New Secret” />
    <add key=SecondaryClientSecret value=Old Secret />
We will keep the Old key in App setting (SecondaryClientSecret) because the new key will take about 12 hours to be generated in this case the web application will try to use the new Client Secret key but it will fail then it will use the secondary key, once the new key generated the web application will use it
References

Replace an expiring client secret in a SharePoint Add-in

Renew an expiring client secret in a SharePoint Provider Hosted Apps (Add-in) without deploying the Apps again by changing Client Secret key using Powershell

When you create Provider Hosted you have registered a Client ID and Secret ID using SharePoint Register App Page (AppRegNew.aspx) and you have used this Client ID and Secret ID in the Web Config in the web application part of the provider hosted app (App Web), after one year your Apps is stop working, and you will get the following Error:
System.IdentityModel.Tokens.SecurityTokenException: Invalid JWT token. Could not resolve issuer token.
Why?
By default the Secret Key will expire after one year, unfortunately you will not get any alerts before the expiry date, you have to renew the Secret Key at least one day before its expiry, because the new key will take about 12 hours to be generated, following steps will renew the Secret ID
      1.       Use online power shell to create new Client Secret ID
Download the Power shell for Office36:

  •          Microsoft Online Services Sign-In Assistant is installed on the development computer.
  •          Microsoft Online Services PowerShell Module (32-bit; 64-bit) is installed on the development computer.
  •      You are a tenant administrator for the Office 365 tenant (or a farm administrator on the farm) where the app was registered with the AppRegNew.aspx page.
        After downloading the powershell open it and connect to SharePoint online using following     CMDLET:
        Connect-MsolService
        A popup will ask for Username and Password type your Username as:     UserName@DomainName.com
    2.       Find out the expiration dates of the apps for SharePoint installed to the Office 365 tenancy
Get-MsolServicePrincipal  |Where-Object -FilterScript { ($_.DisplayName -notlike “*Microsoft*”) -and ($_.DisplayName -notlike “autohost*”) -and  ($_.ServicePrincipalNames -notlike “*localhost*”) } | foreach-object{
    $principalId = $_.AppPrincipalId
    $principalName = $_.DisplayName

    Get-MsolServicePrincipalCredential -AppPrincipalId $principalId -ReturnKeyValues $true | Where-Object { ($_.Type -ne “Other”) -and ($_.Type -ne “Asymmetric”) } |  foreach-object{
        $date = $_.EndDate.ToShortDateString()
        write-output “$($principalName);$($principalId);$($_.KeyId);$($_.type);$($date);$($_.Usage);$($_.Value)”
    }
} > c:\temp\appsec.txt

    3.       Generate a new secret
$clientId = ‘SPECIFY YOUR CLIENT ID HERE’
$bytes = New-Object Byte[] 32
$rand = [System.Security.Cryptography.RandomNumberGenerator]::Create()
$rand.GetBytes($bytes)
$newClientSecret = [System.Convert]::ToBase64String($bytes)
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Password -Usage Verify -Value $newClientSecret
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Symmetric -Usage Sign -Value $newClientSecret
New-MsolServicePrincipalCredential -AppPrincipalId $clientId -Type Symmetric -Usage Verify -Value $newClientSecret
$newClientSecret
Copy the new Secret to use it as mentioned in the next Section
    4.       Update the web Config of the Azure Apps Web with the new Secret
The good news is that it’s not required to deploy the Apps again, you just you need to updated the web config file of the web application part of the provider Hosted App (App Web)
    <add key=ClientId value=c86eb4d4-0efd-4269-92ba-97fd48689ec5 />
    <add key=ClientSecret value=“New Secret” />
    <add key=SecondaryClientSecret value=Old Secret />
We will keep the Old key in App setting (SecondaryClientSecret) because the new key will take about 12 hours to be generated in this case the web application will try to use the new Client Secret key but it will fail then it will use the secondary key, once the new key generated the web application will use it
References

Replace an expiring client secret in a SharePoint Add-in