Fixing HTTP Error 405 Method Not Allowed

On an IIS hosted site I was receiving HTTP 405 error when I tried to access an API call with a PUT method.

Looking at the details page of the error, it was complaining about WebDAV not permitting the PUT verb.

At first, I just tried adding PUT in the default website’s Handler Mappings, doing an iisreset and trying the API call again. This gave me the same error.

So, I decided to remove the WebDAV module from IIS with the “Add and Remove Features” tool. This gave me a new error:

HTTP Error 500.21: Handler “WebDAV” has a bad module “WebDAVModule” in its module list. Going back to IIS, I removed WebDAV completely from the Handler Mappings, did an iisreset and the site started working.

SCSM 2012 Transform.Common fails at TransformEntityRelatesToEntityFact

I had the same problem as Carol and Enayathulla described in this post: https://social.technet.microsoft.com/Forums/systemcenter/en-US/096fd3e1-61fd-4101-a4e6-1de0c6c5ec4c/scsm-2012-transform-job-failing-in-datawarehouse?forum=systemcenterservicemanager and this script seems to have fixed it (at least for the moment):

https://blogs.technet.microsoft.com/mihai/resetting-and-running-the-service-manager-data-warehouse-jobs-separately/

Copying the script in case the link above goes away for some reason. But I recommend reading that post. It’s very informative.:

[CmdletBinding()]
Param(
[Parameter(Mandatory = $False)]
[String] $DWServer = “localhost”,
[Parameter(Mandatory = $False)]
[String] $ASServer = “localhost”,
[Parameter(Mandatory = $False)]
[String] $ASDBName = “DWASDatabase”,
[Parameter(Mandatory = $False)]
[int] $Wait = 10
)
$props = Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\System Center\2010\Common\Setup”
$instdir = $props.InstallDirectory
$dwpsd = $instdir + “Microsoft.EnterpriseManagement.Warehouse.Cmdlets.psd1”
Import-Module -Name $dwpsd
$JSList = Get-SCDWJobSchedule -ComputerName $DWServer;
$JList = Get-SCDWJob -ComputerName $DWServer;
function Run-DWJob([String]$DWServer, [String]$JobName) {
Write-Host “Enabling and running Job:” $JobName;
Enable-SCDWJob -ComputerName $DWServer -JobName $JobName;
Start-SCDWJob -ComputerName $DWServer -JobName $JobName;
$currentJobStatus = Get-SCDWJob -JobName $JobName -ComputerName $DWServer | Select Status
while($currentJobStatus.Status -eq “Running”) {
Start-Sleep -s $Wait
$currentJobStatus = Get-SCDWJob -JobName $JobName -ComputerName $DWServer | Select Status
$moduleList = Get-SCDWJobModule -JobName $JobName -ComputerName $DWServer
foreach($obj in $moduleList) {
if([String]::IsNullOrEmpty($obj.ModuleErrorSummary) -ne $true) {
Write-Host “There is no need to wait anymore for Job” $JobName “because there is an error in module” $obj.ModuleName “and the error is:” $obj.ModuleErrorSummary;
exit;
}
}
}
if($currentJobStatus.Status -ne “Not Started”) {
Write-Host “There is an error with” $JobName “and we will exit this – please inspect the status”;
exit;
}
}
foreach($obj in $JSList) {
Write-Host “Disabling Schedule for Job: ” $obj.Name;
Disable-SCDWJobSchedule -ComputerName $DWServer -JobName $obj.Name;
}
foreach($obj in $JList) {
Write-Host “Stoping and disabling Job: ” $obj.Name;
Stop-SCDWJob -ComputerName $DWServer -JobName $obj.Name;
Start-Sleep -s $Wait
Disable-SCDWJob -ComputerName $DWServer -JobName $obj.Name;
}
$maintenanceList = New-Object System.Collections.ArrayList;
$MPSyncList = New-Object System.Collections.ArrayList;
$extractList = New-Object System.Collections.ArrayList;
$transformList = New-Object System.Collections.ArrayList;
$loadList = New-Object System.Collections.ArrayList;
$cubeList = New-Object System.Collections.ArrayList;
foreach($obj in $JList) {
if($obj.Name -match “Extract”) {
$extractList.Add($obj.Name) | Out-Null;
} elseif($obj.Name -match “Transform”) {
$transformList.Add($obj.Name) | Out-Null;
} elseif($obj.Name -match “Load”) {
$loadList.Add($obj.Name) | Out-Null;
} elseif($obj.Name -match “Maintenance”) {
$maintenanceList.Add($obj.Name) | Out-Null;
} elseif($obj.Name -match “MPSync”) {
$MPSyncList.Add($obj.Name) | Out-Null;
} else {
$cubeList.Add($obj.Name) | Out-Null;
}
}
foreach($obj in $maintenanceList) {
Run-DWJob $DWServer $obj;
}
foreach($obj in $MPSyncList) {
Run-DWJob $DWServer $obj;
}
foreach($obj in $extractList) {
Run-DWJob $DWServer $obj;
}
foreach($obj in $transformList) {
Run-DWJob $DWServer $obj;
}
foreach($obj in $loadList) {
Run-DWJob $DWServer $obj;
}
foreach($obj in $cubeList) {
Run-DWJob $DWServer $obj;
}
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.AnalysisServices”) | Out-Null;
$Server = New-Object Microsoft.AnalysisServices.Server;
$Server.Connect($ASServer);
$Databases = $Server.Databases;
$DWASDB = $Databases[$ASDBName];
$Dimensions = New-Object Microsoft.AnalysisServices.Dimension;
$Dimensions = $DWASDB.Dimensions;
foreach($dim in $Dimensions) {
Write-Host “Processing Cube Job” $Dim.Name;
$dim.Process(“ProcessFull”);
Start-Sleep -s $Wait;
}
foreach($obj in $JSList) {
Write-Host “Enabling Schedule for Job: ” $obj.Name;
Enable-SCDWJobSchedule -ComputerName $DWServer -JobName $obj.Name;
}
Write-Host “”;
Write-Host “FINISHED!”;

MIM 2016 Upgrade to SP1 Popups Stuck on Loading

After upgrading to MIM 2016 SP1, any client that had previously connected to the portal would get hanging popup pages where the spinner just kept going endlessly.

Thanks to some help at the FIM forum indicating that the popup.aspx page should be edited, I figured out a workaround for my site at least:

In the SharePoint 14 hive:

Keep in mind that updates to SharePoint or MIM could wipe all of these changes out.

 

MIM 2016 Upgrade to MIM 2016 SP1 Fails on Second FIM Service Server

Weird one: the upgrade to SP1 on the first MIM Service server went OK (a few hiccups with a missing data type in SQL, but I was able to create those and the upgrade went fine).

However, the installation on the second MIM Service server failed with very little information of any use in the log file.

I decided to uninstall MIM and got an error that the web application at “http://mysite.mydomain.com” did not exist. Sure enough, that Alternate Access Mapping was missing in SharePoint Central Admin on the second MIM Service server’s SharePoint configuration. I stopped the uninstall, added the AAM and the SP1 Upgrade finished successfully.

FIM: Send notification to requestor when request is approved

We needed to send a notification to the requestor when the request was approved. Out of the box, the approval workflow will send a notification to the requestor on rejection or expiration of the request, but not on approval. (That notification goes to the approver.)

After a little thinking, it wasn’t too hard to do.

1. Created the appropriate email template with what we wanted to communicate to the requestor.

2. Created a set of “ApprovalResponse” objects with a Decision of “Approved” and a display name that started with “Update to Group”.

3. Created a workflow with a notification activity. This was the only tricky part. The UI did not let us have [//Target/Requestor] as the recipient. We created the initial workflow and then edited the XOML via the “Extended Attributes” tab to change the recipient to [//Target/Requestor].

4. Created a management policy rule of “Request” type. The set of requestors is a set that only includes the FIM Web Service account (which is the account that originates the creation of the Approval Response object. The action was “Create” and the target resource was the set we created in step two. The policy workflow was the one we created in step 3.

Enable-CSUser Insufficient Permission

Enabling users from both the Lync control panel and PowerShell was producing this error:

“Active Directory operation failed on “abc.domain.com”. You cannot retry this operation: “Insufficient access rights to perform the operation
00002098: SecErr: DSID-03150E8A, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
“.You do not have the appropriate permissions to perform this operation in Active Directory. One possible cause is that the Lync Server Control Panel and Remote Windows PowerShell cannot modify users who belong to protected security groups (for example, the Domain Admins group). To manage users in the Domain Admins group, use the Lync Server Management Shell and log on using a Domain Admins account. There are other possible causes. For details, see Lync Server 2010 Help.”

Most solutions to this topic mention ensuring that Inheritable Permissions are set on the user’s security tab in AD, but in our case these were already set.

A user with Domain Admin privileges could enable the users but not our Lync Admin account that had both CSAdministrator and RTCUniversalUserAdmins membership.

After much head scratching, it turned out that the Lync server had been removed from the membership in the RTCUniversalUserAdmins group. Adding the computer back to that group was the solution.