Error: New-AzResourceGroupDeployment: Cannot retrieve the dynamic parameters for the cmdlet. Cannot find path ‘.json’ because it does not exist.

I received the above error today whilst working on a new Bicep template which caused me a bit of confusion as it seemed to be indicating that a file was missing.

What I figured out in the end is that it was really saying that I had messed up something in my Bicep template file (in this instance I had mis-typed a parameter name). I suspect that during ‘compilation’ Bicep creates a .json file which corresponds to the equivalent ARM template and because it could not create this file due to the error it was showing me this slightly misleading message instead.

So if anyone else receives this error it is probably worth checking your bicep file before looking for anything more complicated.

SharePoint 2013 Error: The filtering process has been terminated

I had just completed a PowerShell scripted deployment of a SharePoint farm and was just performing the final checks when I noticed the following error in the crawl logs.

The filtering process has been terminated

This turned out that because in the PowerShell script I had specified that the SharePoint installation location should be different to the default location.  The SharePoint installation routine had not associated the correct permissions for the WSS_WPG group.

In my instance I had specified that SharePoint should be installed onto a non system disk and I had also specified different directories for indexes and logs.

To fix this I added the WSS_WPG with full control to the following directories.

%:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\Applications
c:\Windows\Temp
%:\SharePoint\Index

Once the correct permissions had been applied I ran a full crawl and no longer received this error.

Exchange 2013 Preview: Error connecting to server via PowerShell after installation

After installing the pre-requisites and installing Exchange, when connecting to the exchange server using the Exchange Management Shell you may receive an error similar to the following.

“The WS-Management service does not support the request. For more information, see the about_Remote_Troubleshooting Help Topic”

It appears that the setup routine may not always register the .NET framework on IIS, so to get this to work you need to register .NET Framework 4 on IIS manually. To do this run the following command from an administrative command prompt.

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

then restart IIS, this should solve the problem.

Error message when you view an Outlook Web App Web Part in a SharePoint Online site in Office 365: “This content cannot be displayed in a frame”

Over the last couple of weeks I have been working on an Office 365 project, and whilst in general I have been impressed with the SharePoint aspects of Office 365.  There have been a couple of gotchas.  I will be positing a couple of articles dealing with these in more detail.  Anyway, I thought it would be a good idea to allow users in their mysites view there mails, contacts, tasks etc.

Office 365 handily provides web parts for this function.  I added these to a page and configured them to look at the appropriate Exchange online instance.  However, once loaded the web parts displayed the following error.

“This content cannot be displayed in a frame”

It appears that the outlook web parts will only work and display the relevent information if the user is already authenticated and logged in to O365 Outlook in a another browser session.  The following article provides more information on this behaviour.

http://support.microsoft.com/kb/2495854

BizTalk WSS Adapter: HTTP 401.2 – Unauthorized: Logon failed due to server configuration

Continuing my experience of attempting to configure the WSS adapter for a clients BizTalk/SharePoint integration project.  As mentioned in my previous post I was having an authentication issue between the clients SharePoint and BizTalk instances.  The message I was getting back (not in BizTalk unfortunately) was the following 401.2 message.

“HTTP 401.2 – Unauthorized: Logon failed due to server configuration”

Now this turned out to be due to the fact that the site which had the WSS adapter installed was configured to use Kerberos authentication, as I could not see a place to configure the adapters authentication method to use Kerberos I assumed that it was probably trying to connect via NTLM authentication instead, causing the error.  To get around this I completed the following steps.

1. Extended the SharePoint site
2. Configured the extended site to use NTLM authentication
3. Added the new site to the alternate access mappings
4. Removed the WSS adapter from the existing site
5. Installed/configured the WSS adapter on the newly extended site.
6. Modified the send port in BizTalk to use the new URL

Once I had completed these steps I was able to communicate with the SharePoint Server.