My latest article helps explain how NIST recommendations can help mange digital identities. NIST isn’t really a compliance standard so following their guidelines won’t get you a neat certificate of compliance, but they can help protect your digital identities.
Thanks to my colleagues at Keyfactor for their input on this! (That’s you, Ryan Sanders.) 🙂
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.
https://blog.keyfactor.com/prevent-outages
This was inspired by real life events during a girls’ night out.
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):
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!”;
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:
http://%=Microsoft.IdentityManagement.WebUI.Controls.SharePointUtility.PopulateRelativePathFromLayouts(
http://%=Microsoft.IdentityManagement.WebUI.Controls.SharePointUtility.PopulateRelativePathFromLayouts(
Keep in mind that updates to SharePoint or MIM could wipe all of these changes out.
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.
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.
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.
Blogging Accident 