Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.
Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.

Office 365

FIXED – 403 ExecuteQuery CSOM from a SharePoint Server

I came across this error when running CSOM requests to Office 365.   While troubleshooting the CSOM call worked beautifully from “powershell_ise” but not regular “powershell.”  Fiddler monitoring showed the cmdlet making HTTP traffic correctly with login handshake from ISE.    However, the regular “powershell” window did not attempt any login handshake.

Strange?   Definitely.

The root cause was “$profile” loading the Server Object Model (SOM) cmdlets before CSOM DLL were loaded.   Why would that matter?  How could it cause a CSOM issue?   There seems to be a DLL namespace overlap internally between these plugins (SOM, CSOM, SPO) so loading sequence matters.  A lot.

By proactively loading the CSOM DLL in $profile before SOM, everything worked correctly from both ISE and the regular PowerShell console.

Hope this helps! 

shades_smile

 

Symptom

  1. Run CSOM request in PowerShell
  2. From a SharePoint Server on premise (2013 here)
  3. Which also has Microsoft SharePoint Online (SPO) cmdlets installed (https://www.microsoft.com/en-us/download/details.aspx?id=35588)
  4. See this error
  5. Exception calling “ExecuteQuery” with “0” argument(s):  “The remote server returned an error:  (403) Forbidden.

 

Screenshot

image
2016-08-07_11-33-34

Resolution

  1. Open PowerShell and type “notepad $profile”
  2. Ensure below code is present.
  3. NOTE – CSOM must load before SOM (Server Object Model) for requests to execute correctly.   Workaround for an internal Microsoft naming overlap.  Both are probably using the same object somewhere.  Loading CSOM first allows CSOM to reserve the namespace first.

 

Code [$profile]

 

 

Code [csom-only-test.ps1]

Office 365 – Baby Proof SharePoint

Ever enabled a Site Feature out of curiosity?  I sure have.  Great way to learn, but can make support headaches too.   Confusing menus, extra list instances, extra content types, and more surface area to juggle.

Why not try “Baby Proofing” SharePoint in Office 365 by hiding unwanted features?    Client side JavaScript with JQuery CSS selectors can easily hide interface elements during page load.

IT benefits with standardize governance, reduced support calls, and easier migration.   Business benefits with a simpler easy to navigate menu.  Good for both sides.

Less is more!  Give it a try. 

shades_smile

PowerShell and JS available on GitHub at https://github.com/spjeff/office365/blob/master/office365-gpo/office365-gpo.js 

PowerShell Enable

 

Screenshot – Before

b
image

 

 

Screenshot – After

a
image

 

Source Code

https://github.com/spjeff/office365/blob/master/office365-gpo/office365-gpo.js

VIDEO – Secure WebAPI with AzureAD

I recorded a quick getting started video for this Microsoft GitHub sample.   Walks through all the steps and even shows the SQL Local DB storage and how to verify security with Fiddler Composer sending test HTTP traffic. 

This pattern is a great way to enhance Officer 365 SharePoint team sites with advanced functionality.   Host AngularJS single page application (SPA) on the front end along with an Azure AD secured WebAPI backend.   Lots of potential for replacing traditional WSP farm solutions with new cloud development patterns.

Enjoy! 

shades_smile

 

Source Code

https://github.com/Azure-Samples/active-directory-angularjs-singlepageapp-dotnet-webapi

 

Video

InfoPath tip – detect Security Group with List Item permissions

Yes, everyone says InfoPath is dead … but we’re all still supporting it for a while so I wanted to share one of my favorite tips.  Forms often need role based security at the field level.  Table below with example security matrix.

How can InfoPath detect that?   Don’t some people query SOAP ASMX?   Or even a custom WSP with a custom ASMX?   There is a simpler way with List Item permission.  

image
  1. Create a new Custom List named “SecurityLevel” with only the default “Title” column.  
  2. Go create the needed SharePoint Groups under Site Permissions.  
  3. Back in “SecurityLevel” add one new item for each SharePoint Group with an identical name.   Hover that item, pull down the menu, and set Item Level Permissions for that group ONLY to have “Read” on that item only.  
  4. With InfoPath Designer edit the XSN Form Template and create a new Data Connection to the list “SecurityLevel” with auto refresh.  
  5. Under Form Load create a rule … if count(SecurityLevel [“Analyst”]) > 0 then set field “SecurityLevel=Analyst”.   
  6. With that in place you are ready to apply formatting rules anywhere needed that use “SecurityLevel” to determine hide/show or read/write.

 

Voila!

Now when a user open the InfoPath form, the data connection “SecurityLevel” will only show the items they have access to (which is the same as the SharePoint Group membership!).    Works on MOSS 2007, SharePoint 2010, SharePoint 2013, and Office 365.

Hope this helps.  Please leave a comment if it did. 

shades_smile

 

DOWNLOAD  InfoPath Form – SecurityLevel.xsn >>

 

 

image
image
image
image
image

 

image
image
image

© Copyright 2016
@ SPJeff

Return to Top ▲Return to Top ▲