I'm using Sitecore Powershell Extensions to unlock items that have been locked for an extended period of time. The script is stored in the script library:

$item = Get-Item -Path master:\content\
$daysToAllowLock = 5
$allowedLockDate = (Get-Date).AddDays($daysToAllowLock * -1)

$itemsToUnlock = Get-ChildItem -Path $item.ProviderPath -Recurse -Version * -Language * | Where-Object { $_.__Lock -and (-not ($_.__Lock -match "<r />")) -and ($allowedLockDate -gt ([Sitecore.Data.Fields.LockField]($_.Fields["__Lock"])).Date)}

Write-Log "Unlocking items locked before $allowedLockDate"

foreach($item in $itemsToUnlock){
    $language = $item.Language
    $path = $item.ItemPath
    $lockedDate = ([Sitecore.Data.Fields.LockField]($item.Fields["__Lock"])).Date
    Write-Log "Unlocking item $path [$language]. Locked by $lockedBy on $lockedDate"
    Unlock-Item -Item $item

When I execute the from Powershell ISE it runs fine and unlocks the items I expect it to unlock. I have it writing log messages to indicate which items are unlocked. For my purposes, I created a scheduled task to execute the script once per day to do the check/unlock. However, when the script executes via the scheduled task it does NOT unlock the items.

When I check the logs there are no errors related to the task and it logs messages identically as though it is unlocking the items.

ManagedPoolThread #4 11:01:19 INFO Starting: Unlock items locked for longer than 5 days ManagedPoolThread #4 11:01:19 INFO Executing a Sitecore PowerShell Extensions script. ManagedPoolThread #4 11:02:14 INFO Unlocking items locked before 02/03/2017 11:01:19 ManagedPoolThread #4 11:02:14 INFO Unlocking item /sitecore/content/Home/TestCategory/Old Item [en]. Locked by sitecore\Admin on 01/08/2017 15:48:51 ManagedPoolThread #4 11:02:14 INFO Ended: Unlock items locked for longer than 5 days

When I look at the item mentioned in the logs, I can see that it is still locked even though the script was executed successfully.

I'm not sure why this would happen. My guess is that when the scheduled task executes automatically then perhaps there is some type of permissions issue that is causing the unlock to fail silently. This would add up since executing the script from the admin user context works fine. But that is just guess-work.

Any suggestions to resolve this issue?

3 Answers 3


If a trick with security disabler will not work you could try this

$admin = [Sitecore.Security.Accounts.User]::FromName("sitecore\some_admin_account", $false)


  • This worked! So it did indeed seem to be a permissions related issue. Thanks!
    – Rondel
    Feb 8, 2017 at 17:35

It sounds like you are running into a permissions issue. You could try wrapping the whole script in a security disabler like this:

New-UsingBlock(New-Object -TypeName "Sitecore.SecurityModel.SecurityDisabler"){
    # Add your script here

That should prevent any permissions issues.

  • I got an error using this : New-UsingBlock : The term 'New-UsingBlock' is not recognized as the name of a cmdlet, function, script file, or operable program..... My version of PSE doesn't recognize that command
    – Rondel
    Feb 8, 2017 at 17:18
  • what version of SPE are you using?
    – Richard Seal
    Feb 8, 2017 at 17:40
  • I'm on 4.0 I think. It looks like that command was introduced in SPE 4.1
    – Rondel
    Feb 8, 2017 at 17:52

Fot the benefit of the audience, The solution provided by Richard Seal (SecuirtyDisabler) and the solution provided by Alan Płócieniak (UserSwitcher) both works if you are using SPE 4.1 or later. But what is the difference?

SecurityDisabler as name implies, disable all security restriction completely. If there are security limiting access to content or certain functionality, SecurityDisabler disable or override all of that.

UserSwitcher execute the code under the context of the specific user. With UserSwitcher, you can limit what the code can perform (in terms of permission). As an example, you have a user called “ServiceAccount” with read and write access permission to specific items in the content tree. If the code performs a delete action, an AccessDeniedException is thrown. If SecurityDisabler is use in this scenario, the delete action is successful.

Given the difference between the two, it is best practice to use UserSwitcher and avoid using SecurityDisabler as much as possible. UserSwitcher gives you more sense of control on what your code can do in terms of permissions.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.