RSS

How do I - Fix The Standard View of your list is being displayed because your browser does not support running ActiveX controls


After migrating a site from SharePoint 2010 you find that it doesn't display the same way in your new environment. Sure, newer versions of SharePoint is sure to display content slightly differently, but this one's different. Instead of your items scrolling nicely on page in a scrollable box, the entire page now becomes a scrollable grid.

BEFORE MIGRATION

























Notice the Access Web Datasheet grid displaying the content on the page.
Now take a look at the migrated content.

AFTER MIGRATION





















Notice the page scroll bar to the right.  The entire page is now scrolling.  In addition, the error message at the very bottom of the page notes:

"The Standard View of your list is being displayed because your browser does not support running ActiveX controls."

The fix is actually pretty straight forward.
Odds are you're using Internet Explorer 11 or later and like most SharePoint sites, you'll need to tell newer versions of IE to interpret the site in Compatibility Mode.  To achieve this simply:

   1.  Click the settings gear in the top right of IE, just below the closing X.




   2.  Click the "Compatibility View settings" option on the dropdown menu.
























  
   3.  The Compatibility View Settings modal window will be displayed.
   4.  By default your site's root domain will be displayed in the "Add this website:" field as in #1 above.
   5.  Click the "Add" button (#2) in order to add the domain to the list (#3) below.
   6.  Click "Close".
   7.  The site should automatically refresh and the content should load the same way as you're used to.

Enjoy
C

How to improve your SharePoint performance


The speed at which SharePoint operates and its overall performance can be greatly improved by improving the underlying data engine, i.e. SQL Server.

Your SharePoint configuration and SQL Server
The overall performance of your SharePoint farm is dependent on its configuration and settings, although since SQL server is the underlying data engine upon which SharePoint is built, the  faster the information can be written, stored and accessed, the faster the performance of SharePoint.

The Disks and the NTFS Allocation size
In order to enhance the speed of SharePoint, especially when you have a traveling demo VM, you need the required disk size, although if your laptop’s disk size is smaller than the required specifications, it can still be modified to enhance SharePoint performance. This can mostly be achieved by firstly formatting the disk and then changing the NTFS allocation size on your drives. By default, your disk reads and writes 4K at a time, however, SQL reads and writes 64K, which is far greater. Changing the allocation size in NTFS on your drive alone will boost your performance by up to 30%.

Modifying the Model Database to increase SharePoint performance
The SQL utilizes the information in the model Database for creating new databases.  You would think that SharePoint would use the model database, but it actually does not.  As a result, when a new content database is created, by default, the auto grow settings of the database is set to 1 MB at a time and as any SQL DBA worth his salt will tell you, a SQL grow operation is by far the most expensive operation in SQL.  As a result, imagine your content database being full and someone uploading a 100 MB file.  That will require the content database to grow 100 times.  Not good for performance at all.  So always go and check your grow settings after new content databases have been added.

Initial Size
When a new database is created, it is very important to take into consideration its initial size and the purpose of its creation. A larger amount of space should be allotted to a new database when they are created, in order to prevent SQL from constantly asking for more spaces to store data. This will certainly help the overall performance of SharePoint i.e. avoid grow operations as explained in the previous section.

Auto Growth
In the long run, when the database is filled there will be the need for it to grow, you can specifically allocate the size you want it to grow into. Make sure to grow the size of your SharePoint databases by chunks that make sense in your environment. Don't forget the TempDB.  Remember, every write goes through the TempDB first before it goes to your DB!

Instant File Initialization can help speed up SharePoint but be careful
Instant file initiation allows SharePoint to skip certain long processes during the initiation of sizing and the auto growth processes. Talking about increasing those SharePoint Database file sizes, how does it actually do it? Well to make sure it can be written to as it creates or grows the database, SQL will write zeroes to validate it can write to it and then claim it. This can be a very long process depending on the required task SharePoint asked of SQL Server. Performing the instant file initiation will help in saving time and increase the speed of operation. This is especially true for demo machines, but beware that the space must be available.  You do NOT want to run out of space!

0 comments

Posted in

Guys we're back!!!


Hi guys, thanks for bearing with us doing the restructuring of our site. You know at times it is better to take a step backward so as to be able to take three forward. Yes, we're fully back and ready to rock the show with details on SharePoint and we hope to give you the very best Tips. Once again, Thank you so much. 

0 comments

Posted in

Blog consolidation ongoing... please bear with me.


Hey everyone,

Please bear with me as we consolidate all my blog posts from various blogs together under this one source.  My apologies if you see "old" content coming through your feed over the next couple weeks.  This will be eventually serve to make for a better, more complete experience for all going forward.

Thanks!
C

0 comments

Posted in

How do I - Change a SharePoint site URL?


This is probably one of the most common questions I've been asked over the years.  Unfortunately, Microsoft doesn't provide a UI method for users to change the URL of their site.  Given the database schema and the relationships between objects and the URL, I've always been perplexed as to why this was never done.  To me it seemed like a pretty easy SQL update.

Although there are many methods to overcome this problem, such as the site backup/restore method described by Todd Klindt, these methods become increasingly more time consuming as the site size grows.  The easiest method in my mind still remains using the SPSite.Rename() method.  Unfortunately, the MSDN article states at the top that it "Changes the URL of a host-header-named site collection to a new URL.".  I believe this is why this method has remained obscure and under-leveraged.  At the end of the article, it also states "After the site rename, an app pool recycle is recommended to force refreshing the cache." which is incorrect.  An app pool recycle is required in order for the new URL to work correctly.

But enough picking apart MSDN articles... let's get to the good stuff. :-)
The following Powershell script does what we want:



The core of the script is lines 9 and 10.
Remember to recycle your web app's app pool!

Enjoy!
C

How do I - Remove an item from a Powershell array.


Because Powershell is so close in syntax to C#, we often forget that it is in fact, NOT C#.  A good example of this is manipulating arrays.  While Powershell did implement the += method for adding items to an array, it does not support -= for removing them.  Fortunately, the -ne switch serves the same purpose.  See the following example for a quick demonstration of removing items from an array in Powershell.


Enjoy
C

How do I - Remove duplicates from a Powershell array?


When it becomes necessary to remove duplicates from a Powershell array variable, it can quickly be achieved via the -unique switch.  You can even sort at the same time like this:


Enjoy
C

How do I - Validate an Assembly is Loaded in Powershell?


Recently, I ran into an issue when auditing TFS.  The issue was related to an intermittent problem where the Powershell script would sometimes work, and sometimes fail.  From a developer perspective, this is an impossibility.  Code either works or it doesn't.  If it sometimes work, then there is most likely something else at play.
Inevitably this lead me down the path of dependencies.  I had to ensure that we had the right TFS DLLs loaded for the script.  This can easily be done with reflection via the GetAssemblies() method of the CurrentDomain within the AppDomain object in Powershell.  The simple command:

[AppDomain]::CurrentDomain.GetAssemblies()

returns a comprehensive list of loaded DLLs.  From here you can identify if your DLL is loaded, or as was the case in another session for me, identify that wrong versions of the target DLL is loaded.  That's good, but how do I use that logically in Powershell code e.g. when I want to see if a DLL is already loaded before attempting to load it again.  (As we know, that throws ugly red text that the operator might mistake for an error rather than the EXPECTED error it is.)

Therefore, using the pipe, we could do something like this:

([AppDomain]::CurrentDomain.GetAssemblies() | where {$_ -match "Microsoft.TeamFoundation.Client"}).Location -eq ""

As you can see, we pipe the output from GetAssemblies() to the where clause attempting to match with the DLL partial name, e.g. "Microsoft.TeamFoundation.Client" in this case.
By wrapping the entire statement in parentheses, we can access the .Location property of the returned object, provided there is one.  If there is none, the location value would be blank and by doing an equal check for blank, we can get a boolean result statement that identifies if a given DLL is loaded. :-)

Enjoy
C

Beware of [System.Reflection.Assembly]::LoadWithPartialName!!!


If you've been in the Powershell world for any length of time, you will most certainly be familiar with this construct:

[System.Reflection.Assembly]::LoadWithPartialName(...)

This is how we quickly add DLL references to Powershell scripts without having to know the entire name of the DLL in question e.g.

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint");

which loads the Microsoft.SharePoint.dll and makes all the SharePoint cmdlets available to Powershell.

BEWARE!!!  In some cases, quickly = lazy = bad.

If you are referencing a DLL that may have more than hone version on the host system, it becomes imperative that you ensure you are actually loading the right DLL.  I recently ran into this kind of thing when a script was trying to execute some TFS 2015 commands.  The script would fail however, apparently without any logical reason.
It turns out, the reason was quite logical after all.  The script was loading the "Microsoft.VisualStudio.TeamFoundation.dll" using the LoadWithPartialName() method.  Even with the TFS SDK installed, the script would load the wrong version of the DLL since the 2013 version of the exact same named DLL was in the GAC.  Since the GAC trumps everything else, the script would load the old version of the DLL from the GAC and then try to use it with newer versions of related DLLs, hence the failure to execute correctly.

If there's ever any doubt, rather use the best practice LoadFrom() method thus:

[System.Reflection.Assembly]::LoadFrom("C:\Program Files\Common Files\Microsoft Shared\web server extensions\15\ISAPI\Microsoft.SharePoint");

This way, you're 100% guaranteed the proper DLL is loaded and leveraged in your Powershell script.

Enjoy
C

Quick Tip - How to migrate your Windows 7 Sticky Notes to Windows 10


With versions of Windows prior to version 10, the little Sticky Notes app that a lot of people depend on for quick notes (we really should use OneNote instead!) was easily transferred from an old computer to a new computer by simply copying the file located here:

%AppData%\Microsoft\Sticky Notes\StickyNotes.snt

to the same location on the new computer.  With Windows 10, the Sticky Notes app has graduated to the Microsoft App Store so it changed quite a bit.  Notes are no longer stored in that single .snt file and on top of that, there isn't a %AppData%\Microsoft\Sticky Notes folder anywhere to be found.
Fear not.  The solution, courtesy of Donovan Lange, an Engineering Manager for Sticky Notes, is pretty simple, though not well documented.  The following assumes a NEW computer with Windows 10.  If you simply upgrade to Windows 10, Sticky Notes will auto upgrade to the new version.
Simply follow these steps to migrate your old notes from Windows versions prior to 10, to Windows 10:
  1. Open Windows Explorer.
  2. In the address bar, paste the following without the quotes:  "%AppData%\Microsoft\Sticky Notes".
  3. Make a copy of the StickyNotes.snt file you find in this folder to transferable media such as a flash drive.
  4. On the new computer, insert the flash drive and open File Explorer.
  5. In the address bar, paste the following without the quotes: "%LOCALAPPDATA%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbw\LocalState"
  6. You will most likely NOT see a "Legacy" folder in this location.
  7. Right click > New > Folder and name the folder "Legacy" without the quotes.
  8. Double click to drill down to the Legacy folder.
  9. Now navigate to your flash drive and copy the "StickyNotes.snt" file.
  10. Navigate back to the %LOCALAPPDATA%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbw\LocalState\Legacy folder and paste the StickyNotes.snt file here.
  11. Once copied, right click on StickyNotes.snt and rename the file to "ThresholdNotes.snt" without the quotes.
  12. Close File Explorer.
  13. Close the Sticky Notes app.
  14. Restart the Sticky Notes app.
  15. You'll be presented with your old notes AND any notes you've taken in the new app.  You'll also be asked to upgrade the old notes to the new version at this point.
That's it!

Enjoy
C