Powershell remoting - This host does not support transcription.

Feb 25, 2013 at 7:39 PM
Fantastic utility!

When running this in a remote session i get an error stating : "This host does not support transcription."

Is this caused by my remote session or other setup on my part?

I have temporarily solved this by commenting out two lines:
Function StartTracing()    {
            $script:LogTime = Get-Date -Format yyyyMMdd-HHmmss
            $script:LogFile = "$logDir\$LogTime-$Command.log"
            #Start-Transcript -Path $LogFile -Force
            $script:ElapsedTime = [System.Diagnostics.Stopwatch]::StartNew()
        }

function StopTracing(){
            #Stop-Transcript
        }
Coordinator
Feb 25, 2013 at 8:02 PM
Hi boolnordic,

Unfortunately, as far as I know, recording a transcript in a remote session does not work.
See also http://social.technet.microsoft.com/Forums/sv/winserverpowershell/thread/d7d3b869-8e74-4b0f-9960-2143667f3319

To get around that issue you would require to start the transcript on the machine from which you are accessing the remote machine.
So at least you could dump the output/log there.

In my projects I execute the scripts through a custom deployment service which is initiated from TFS on the remote machine after droping the package there.

I will add a switch in a future version to easily turn off the transcript. Then you it is at least not neccesary to alter the script files like you did.

Regards,

Matthias
Feb 25, 2013 at 8:31 PM
Thank you for your reply.

The link you provided explains it all really. We are also using TFS and the build log appears to pick up everything. For now the solution works fine but i am looking forward to future updates.

The remote session I described is used in conjunction with TFS to provide automated builds. The packages are dropped to a file share and that drop location is then passed to $solutionDirectory. I can confirm that with some tweaking to fit our needs this works great.

Currently I am handling deployment dependencies by using custom targets to ensure that some wsp's are always deployed first and retracted last. We miss out on the environment declaration but it provides us the flexibility we need. Perhaps you have encountered the same requirement at times?

Again, a fantastic utility.


Kind regards

/Martin
Coordinator
Feb 25, 2013 at 8:47 PM
Thanks! :-)

I will try that out to see if I find a better way to handle it.

Regarding the deployment dependencies, yes, this is something I am planning to add in the environment XML file schema. It will then be possible then to specify the order how the solutions are deployed.

I am also thinking about allowing to specify optional custom targets for each wsp, so that one can run some scripts before continuing with the next wsp. Still have to come up with a good idea how to code it though. I don't want the environment xml to become too complicated and unmanageable.

BTW, for general prerequisite solutions (which are not deployed through the package) you can specify them in the corresponding section of the environment xml.
The environment editor helps you with that in case you don't want to mess around directly with the xml.

Looking forward to hear more feedback and ideas for improvement :-)

/Matthias