Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running BiosSledgehammer.ps1 from SCCM task sequence #79

Closed
hanfelt opened this issue Oct 18, 2018 · 23 comments
Closed

Running BiosSledgehammer.ps1 from SCCM task sequence #79

hanfelt opened this issue Oct 18, 2018 · 23 comments

Comments

@hanfelt
Copy link

hanfelt commented Oct 18, 2018

Hi there when trying to run Sledgehammer from task sequence it always fails for me. Tried making package, run command, run powershell about everything you can think of. If i hit F8 and run it manually from command i get this error:
Start-TranscriptIfSupported: Cannot validate argument on parameter 'Path'. The argument is null or empty. Provide an argument that is not null or empty, and then try the command again.
At MPSXM.psm1:561 char:9
Start-TranscriptIfSupported - Path $logPath -Name $logName -Ne ....

@texhex
Copy link
Owner

texhex commented Oct 18, 2018

This is odd. Can you please enter the command $PSVerionTable inside a PowerShell command and post the results?

Also, just to be sure: You start this once the OS has started for the first time, not within Windows PE?

@texhex texhex changed the title Running BiosSledgehammer.ps1 from sccm task sequence Running BiosSledgehammer.ps1 from SCCM task sequence Oct 18, 2018
@hanfelt
Copy link
Author

hanfelt commented Oct 18, 2018

Yes at least i have a restart computer task that boots "The currently installed default operating system". before running the Sledgehammer script.
Im running the task right now and once it fails i will post the $PSVerionTable brb.

@hanfelt
Copy link
Author

hanfelt commented Oct 18, 2018

PSVersion: 5.1.17134.1
PSEdition: Desktop
PSComatibleVersions: 1.0 2.0 3.0 4.0 ....
BuildVersion: 10.0.17134.1
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1

@hanfelt
Copy link
Author

hanfelt commented Oct 18, 2018

I commented out the line 561, 565 and 713 in MPSXM.psm1

561 # Start-TranscriptIfSupported -Path $logPath -Name $logName -NewLog
565 # Start-TranscriptIfSupported -Path $logPath -Name $logName
713 # Stop-Transcript
At least it runs now ;)

@texhex
Copy link
Owner

texhex commented Oct 18, 2018

OK, my first guess was that in your image you used an older version of PowerShell, which is clearly not the case. Given that you are using 5.1, it is really, really strange because we had a similar bug in the past with the logging: issue #40.

I think the error starts here in the main script (line 55+):

#log the output
Start-TranscriptTaskSequence -NewLog

However, after the above mentioned bug was identified, I tried my best to work around it. Somehow this does not work for your system, so it would be great if you copy back the original MPSXM.psm1, and start the script with the verbose switch (.\BiosSledgehammer.ps1 -Verbose), and attach the output (a screenshot will do, no text file required) to this issue.

Hopefully the additional output there can help me to understand what is not working.

@datagutten
Copy link
Contributor

I have the same problem, it can not resolve $env:TEMP, so I have set it static to c:\windows\temp

@hanfelt
Copy link
Author

hanfelt commented Oct 18, 2018

I will do that tomorrow at work and then post the result, thanks for all the help.
Update: Sorry didnt have time to do this today had to do other stuff and had to leave early, will get back with report on monday.

@texhex
Copy link
Owner

texhex commented Oct 18, 2018

Hmm, the problem with $env:TEMP again? I thought I had solved this already, but it seems not to be the case. @hanfelt After the verbose run, please also check what PS returns for $env:TEMP.

@texhex
Copy link
Owner

texhex commented Oct 23, 2018

@hanfelt Any updates?

@hanfelt
Copy link
Author

hanfelt commented Oct 24, 2018

@texhex I tried yesterday and put the original file back but forgot to untick continue on error in the task sequence sorry ;) Then we got alot of other work to do so i couldnt continue, im off work today and might be home tomorrow as well (sick kids). I will do this first thing in the morning when im back. sorry for this delay

@texhex
Copy link
Owner

texhex commented Oct 24, 2018

No problem, take your time. I just wanted to make sure this isn't stalled. All the best for your kids!

@hanfelt
Copy link
Author

hanfelt commented Oct 26, 2018

$env:TEMP = "C:\Windows\TEMP"
1
2

@texhex
Copy link
Owner

texhex commented Oct 27, 2018

Thank you, and that's really the worst possible outcome for a log function to cause the entire script to die on the spot.

Let me check tomorrow why logPath could be empty and how to workaround it.

@texhex
Copy link
Owner

texhex commented Oct 28, 2018

I updated the script and hopefully this bug is now fixed.

I have the possible explanations what is happening here:

  • The variable LogPath in your SCCM environment is not set, and BIOS Sledgehammer simply used it as is (even if it's empty). This of course will not work, so we are defaulting to C:\Windows\Temp now.
  • Somehow, this variable is set but PowerShell can not retrieve the value so it's also an empty string. Also defaults to C:\Windows\Temp now.
  • For whatever reason, my script can not determine the script filename. But it requires this to know how to name the log. Now, a second method is tried in this case.

Finally, the Start-Transscript*() functions already had verbose output to know what they are doing, but this was not used by BIOS Sledgehammer when starting it with the -Verbose parameter. This is now the case, so these function will also add verbose output.

Please do the following:

I really hope it will work this time.

@texhex
Copy link
Owner

texhex commented Oct 28, 2018

@datagutten Your issue with $env:TEMP will be checked once the issue for @hanfelt is fixed. If this new version works, it would be great if you could execute it on your system and attach the verbose log to a new issue.

@hanfelt
Copy link
Author

hanfelt commented Oct 29, 2018

@texhex Will try this out tomorrow and get back to you with the result.
Update: Had to go but my collegue said it failed. I need to run this again on thursday morning again and see if it rellay breaks at this part or if it is something else. We have had a messy week with wmi corruption around our network that we had to take care of :)

@texhex
Copy link
Owner

texhex commented Oct 31, 2018

Thanks for the update and sorry to hear that it still not work. A screenshot of the lower part (below the importing functions stuff) where the "real" verbose message begin might help me to understand why it still fails.

@hanfelt
Copy link
Author

hanfelt commented Nov 1, 2018

Seems like it works i tried running it manually and it runs fine. It writes logs to C:\Windows\Temp as well

@texhex
Copy link
Owner

texhex commented Nov 1, 2018

Very good, but when run manually, the entire code that tries to read the data from SCCM is skipped, so there might still be an issue (just saying). If possible, it would be great if you could give it a test run in SCCM, as you said it didn't run OK for your colleagues.

@hanfelt
Copy link
Author

hanfelt commented Nov 1, 2018

Still having to battle the other issue im really sorry for this ;) I just did i quick run today and thought it might be something else bugging out in the task sequence i did hit f8 and ran it from there and it worked. I didnt have time to do more today. Will look into this on monday next time Sorry!

@texhex
Copy link
Owner

texhex commented Nov 1, 2018

No problem, thanks for the update.

@hanfelt
Copy link
Author

hanfelt commented Nov 16, 2018

Sorry for the late update @texhex , but i think everything works as it should, thanks alot for your help on this issue. Have a great weekend.

@texhex
Copy link
Owner

texhex commented Nov 19, 2018

You are welcome, thanks for the update. Here's hope that this will be the last time we need to fix an error in logging.

I will close the issue now.

@texhex texhex closed this as completed Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants