I am getting an item from Sitecore, then taking the return and messing with the FullName to build the URL.

Import-Module -Name SPE

        $Id = [Some Id]

        $session = New-ScriptSession -Username [un]-Password [pw] -ConnectionUri http://sitecorehostname
        $Item = Invoke-RemoteScript -Session $session -ScriptBlock {
                $item = Get-Item -Path "master:/media library" -Id "$($params.id)"
                $item | Get-Member
        } -Arguments @{"id"=$Id}
        Stop-ScriptSession -Session $session

        $Url = $Item.FullPath
        $Url = $Url -replace "^/sitecore/shell/sitecore/", "/-/"
        $Url = $Url -replace "^/sitecore/", "/-/"
        $Url = $Url -replace "^/media library/", "/media/"
        $tempKey = $Item.Key + "/"
        $Url = $Url -replace $tempKey, $Item.Key
        $Url = "http://sitecorehostname" + $Url

At the end of this code, the value of $Url is "http//sitecorehostname[About 1000 spaces]+[$Item.FullPath with replaced strings]

What confuses me is if I take the text of $Item.FullPath and just run some test code below:

$Url = "/sitecore/media library/Images/ThatOneImage"
$Url = $Url -Replace "^/sitecore/shell/sitecore/", "/-/"
$Url = $Url -Replace "^/sitecore/", "/-/"
$Url = $Url -Replace "^/media library/", "/media/"

I get a proper URL without all the extra spaces. What am I missing?

2 Answers 2


The first change I can see here that I would make is to not return the entire item. SPE serializes the entire item and re-hydrates on the other end. From your example you only need the FullPath.

Import-Module -Name SPE

$Id = "{6AA5AA9F-071A-4808-91AC-709FAAFFB310}"

$session = New-ScriptSession -Username "admin" -Password "b" -ConnectionUri https://remotesitecore
$Url = Invoke-RemoteScript -Session $session -ScriptBlock {
    $item = Get-Item -Path "master:/media library" -Id "$($params.id)"
} -Arguments @{"id"=$Id}
Stop-ScriptSession -Session $session

$Url = $Url -replace "/sitecore/shell/sitecore/", "/-/"
$Url = $Url -replace "/sitecore/", "/-/"
$Url = $Url -replace "/media library/", "/media/"
$tempKey = $Item.Key + "/"
$Url = $Url -replace $tempKey, $Item.Key
$Url = "http://sitecorehostname" + $Url

When I run it I don't get the trailing spaces. You can however simply call Trim on the string and it'll take care of it.


You can also change the script to return a specific set of properties. You'll essentially get a skinny object back.

$item | Select-Object -Property Name, ID, FullPath
  • I needed more data, so I ended up passing back an array of properties. But this is a correct answer, so I will select it as the answer. Aug 15, 2017 at 21:18
  • I updated the answer to cover a scenario where you need more properties. Aug 15, 2017 at 21:23

Instead of parsing the Media Item Path and building up the URl yourself, you should instead use the MediaManager.GetMediaUrl() method to return the URL. If you are string parsing from Item Path then it also will not include the file extension.

$site = [Sitecore.Sites.SiteContextFactory]::GetSiteContext("website")
$mediaItem = Get-Item -Path "master:" -Id "{6AA5AA9F-071A-4808-91AC-709FAAFFB310}"

$Url = New-UsingBlock (New-Object Sitecore.Sites.SiteContextSwitcher $site) {

$Url = "http://sitecorehostname" + $Url

This ensures that any custom Link Provider that may be implemented is also used.

Note: If your Media.AlwaysIncludeServerUrl setting is true then you will need to call the overloaded GetMediaUrl method and pass in MediaUrlOptions and set the value to false (else strip out the current server URL).

  • Be good if this also included request protection. As seen here: sitecore.stackexchange.com/questions/1230/…
    – Mark Cassidy
    Aug 16, 2017 at 17:38
  • @MarkCassidy: Request protection is only required if parameters are being manipulated, e.g. height/width. Just to request the default image size it makes no difference. I can update the example to show this (but also reluctant since issue the OP had was related to the remote call itself). Let me know and I'll update if you think it will be useful.
    – jammykam
    Aug 16, 2017 at 17:59
  • My bad. Misread documentation; thought we were meant to always protect media Urls these days :-)
    – Mark Cassidy
    Aug 16, 2017 at 18:01

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.