SharePoint 2013 Service Cannot be Activated on host-named Site Collection

A host-named site collection on SharePoint has a URL format of apps.ozkary.com. In comparison, a path-based site collection has this URL ozkary.com/sites/apps.

When using a host-named site collection for document libraries, we may encounter some behavior that it is not reproducible when using a path-based site.  Let’s take a look at this service activation error.

Unable to activate service Error

Browser Error

This is error shown on the browser console.

https://apps.ozkary.com/_vti_bin/DocControl/DocControlService.svc/MoveFile 500 (System.ServiceModel.ServiceActivationException)

Server Error

This is the error shown on the server logs.

WebHost failed to process a request. System.ServiceModel.ServiceActivationException: The service '/_vti_bin/DocControl/DocControlService.svc' cannot be activated due to an exception during compilation.  The exception message is: The type 'DocControl.Controls.ISAPI.DocControl.DocControlService, DocControl.Controls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=, provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found

This error indicates that the service cannot be activated because it is not found.  This is a problem on the fact that the relative path the service activation is using is not found because our site is a host-named URL, and there is nothing defined on IIS for this path. A host-named URL is managed internally by SharePoint, so this is the reason why IIS may not have the URL defined on the site bindings.  A solution for this problem is to configure the site on IIS and add this URL to the site bindings.

After adding the binding, the operation that was causing the error should work properly.

I hope this helps.

Originally published by ozkary.com

Move an Azure Subscription to a Different AD Directory

When managing multiple Azure AD and subscriptions, we need to create subscription on a particular Azure AD to grant access to the users in the directory. This allows us to prevent unauthorized access to other subscriptions. In some cases, we may want to transfer a subscription to a different AD directory. 

As of the time of this article, the new Azure portal does not enable this operation. In order to do that, we have to use the Azure AD portal and then load the Classic portal for the final transfers. Let’s see how that is done:

Transfer subscription to different directory

• Login with the account that has the subscription to aad.portal.azure.com

• Click on Azure Active Directory menu option

• Click on Classic Portal (top menu bar)

• On the Top-Right, select Subscriptions (ref image 1)

• Filter by the directory where the subscription is located

• Click on Manage subscription directory

• Select the subscription that we want to transfer

• Select on edit directory (bottom button - ref image 2)

• Select the target directory

• Click continue (right arrow) and make sure that there are no problems with users that do not exist on the target directory.  This means that the owner must exist on both directories.

• Click OK (Check mark)

image 1

image 2

The subscription should be moved to the new directory in a few minutes. After this is successful, we can log back in to Azure portal. We need to make sure that we select the correct directory from the top-right user profile component. There we can find a list of all the directories the user is associated with.

We can now load this URL. There is no menu option to load this view, so we can create a shortcut on the dashboard with this link.


https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade

If we only click on the subscription menu option that it is available from the billing blade area, we see only the subscriptions with associated billing, and that filters our newly transferred subscription.

This should help us move our subscriptions to another AD directory without too much pain.

Originally published by ozkary.com