Calling powershell from batch

Continue

Calling powershell from batch

Aside - This post has received many tangential questions in the comments. Your best bet at getting an answer to those questions is to check Stack Overflow and/or post your question there. A while ago in one of my older posts I included a little gem that I think deserves it's own dedicated post; calling PowerShell scripts from a batch file. Why call my

PowerShell script from a batch file? When I am writing a script for other people to use (in my organization, or for the general public) or even for myself sometimes, I will often include a simple batch file (i.e. *.bat or *.cmd file) that just simply calls my PowerShell script and then exits. I do this because even though PowerShell is awesome, not

everybody knows what it is or how to use it; non-technical folks obviously, but even many of the technical folks in our organization have never used PowerShell. Let's list the problems with sending somebody the PowerShell script alone; The first two points below are hurdles that every user stumbles over the first time they encounter PowerShell (they

are there for security purposes): When you double-click a PowerShell script (*.ps1 file) the default action is often to open it up in an editor, not to run it (you can change this for your PC). When you do figure out you need to right-click the .ps1 file and choose Open With ?> Windows PowerShell to run the script, it will fail with a warning saying that the

execution policy is currently configured to not allow scripts to be ran. My script may require admin privileges in order to run correctly, and it can be tricky to run a PowerShell script as admin without going into a PowerShell console and running the script from there, which a lot of people won't know how to do. A potential problem that could affect

PowerShell Pros is that it's possible for them to have variables or other settings set in their PowerShell profile that could cause my script to not perform correctly; this is pretty unlikely, but still a possibility. So imagine you've written a PowerShell script that you want your grandma to run (or an HR employee, or an executive, or your teenage

daughter, etc.). Do you think they're going to be able to do it? Maybe, maybe not. You should be kind to your users and provide a batch file to call your PowerShell script. The beauty of batch file scripts is that by default the script is ran when it is double-clicked (solves problem #1), and all of the other problems can be overcome by using a few

arguments in our batch file. Ok, I see your point. So how do I call my PowerShell script from a batch file? First, the code I provide assumes that the batch file and PowerShell script are in the same directory. So if you have a PowerShell script called "MyPowerShellScript.ps1" and a batch file called "RunMyPowerShellScript.cmd", this is what the batch

file would contain: @ECHO OFF SET ThisScriptsDirectory=%~dp0 SET PowerShellScriptPath=%ThisScriptsDirectory%MyPowerShellScript.ps1 PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%'"; Line 1 just prevents the contents of the batch file from being printed to the command prompt (so it's optional). Line

2 gets the directory that the batch file is in. Line 3 just appends the PowerShell script filename to the script directory to get the full path to the PowerShell script file, so this is the only line you would need to modify; replace MyPowerShellScript.ps1 with your PowerShell script's filename. The 4th line is the one that actually calls the PowerShell script

and contains the magic. The ?NoProfile switch solves problem #4 above, and the ?ExecutionPolicy Bypass argument solves problem #2. But that still leaves problem #3 above, right? Call your PowerShell script from a batch file with Administrative permissions (i.e. Run As Admin) If your PowerShell script needs to be run as an admin for whatever

reason, the 4th line of the batch file will need to change a bit: @ECHO OFF SET ThisScriptsDirectory=%~dp0 SET PowerShellScriptPath=%ThisScriptsDirectory%MyPowerShellScript.ps1 PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File

""%PowerShellScriptPath%""' -Verb RunAs}"; We can't call the PowerShell script as admin from the command prompt, but we can from PowerShell; so we essentially start a new PowerShell session, and then have that session call the PowerShell script using the ?Verb RunAs argument to specify that the script should be run as an administrator. And

voila, that's it. Now all anybody has to do to run your PowerShell script is double-click the batch file; something that even your grandma can do (well, hopefully). So will your users really love you for this; well, no. Instead they just won't be cursing you for sending them a script that they can't figure out how to run. It's one of those things that nobody

notices until it doesn't work. So take the extra 10 seconds to create a batch file and copy/paste the above text into it; it'll save you time in the long run when you don't have to repeat to all your users the specific instructions they need to follow to run your PowerShell script. I typically use this trick for myself too when my script requires admin rights,

as it just makes running the script faster and easier. Bonus One more tidbit that I often include at the end of my PowerShell scripts is the following code: # If running in the console, wait for input before closing. if ($Host.Name -eq "ConsoleHost") { Write-Host "Press any key to continue..." $Host.UI.RawUI.FlushInputBuffer() # Make sure buffered

input doesn't "press a key" and skip the ReadKey(). $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyUp") > $null } This will prompt the user for keyboard input before closing the PowerShell console window. This is useful because it allows users to read any errors that your PowerShell script may have thrown before the window closes, or even just so

they can see the "Everything completed successfully" message that your script spits out so they know that it ran correctly. Related side note: you can change your PC to always leave the PowerShell console window open after running a script, if that is your preference. I hope you find this useful. Feel free to leave comments. Happy coding! Several

people have left comments asking how to pass parameters into the PowerShell script from the batch file. Here is how to pass in ordered parameters: PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' 'First Param Value' 'Second Param Value'"; And here is how to pass in named parameters: PowerShell -NoProfile

-ExecutionPolicy Bypass -Command "& '%PowerShellScriptPath%' -Param1Name 'Param 1 Value' -Param2Name 'Param 2 Value'" And if you are running the admin version of the script, here is how to pass in ordered parameters: PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -

ExecutionPolicy Bypass -File """"%PowerShellScriptPath%"""" """"First Param Value"""" """"Second Param Value"""" ' -Verb RunAs}" And here is how to pass in named parameters: PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File

""""%PowerShellScriptPath%"""" -Param1Name """"Param 1 Value"""" -Param2Name """"Param 2 value"""" ' -Verb RunAs}"; And yes, the PowerShell script name and parameters need to be wrapped in 4 double quotes in order to properly handle paths/values with spaces. How do you convert your Windows Batch scripts to PowerShell? The basic

"how" is ridiculously easy: Rename the file from .bat/.cmd to .ps1. If it runs exactly the same as it did before, you're done. Bravo. But if it doesn't run exactly the same way as it did before, you have to prepare to rewrite it. There are no translation tools available (we've searched), so you have to do it by hand, line-by-line, and discover what worked in

your Batch script but doesn't in PowerShell. This requires knowing how to read Windows Batch and how to write PowerShell. There are SO many resources you can find on Google to help you learn both of these. That's why this article isn't about that. Batch is old. Batch is arcane. But Batch still works. Have you ever stopped to ask yourself why

should I convert my Windows Batch scripts to PowerShell? There's a better way to approach the migration from Batch to PowerShell, starting with the question, "Do I have to migrate at all?" Don't rush to migrate your Windows Batch scripts to PowerShell just because they're old or should be modernized. Instead, consider why each Batch script

should be migrated and when it's necessary to migrate before even thinking about how to execute the migration. Use the three scorecards below on complexity, length, and impact to quantify the timeline for migrating your Windows Batch scripts to PowerShell. Windows Batch Script is an Arcane Technology Batch scripts, at this point, are pretty

ancient. Ancient isn't in and of itself bad. Many Batch files are more than a decade old and still execute exactly as expected. No problems. But as the years pass and employees move on, "ancient" becomes "arcane," which is when problems arise. "Arcane" means "understood by few; mysterious or secret." Those who wrote these Batch scripts (and

could read them and understood how they functioned) are probably long gone from your organization. While the scripts might still work, current employees likely don't know what they're looking at, how it works, and most importantly how to fix it if something goes wrong. Basically no one has any idea how complex Windows Batch scripts work

anymore, because they don't have to. Things that a PowerShell script today can accomplish were done with very complicated Batch Scripts back in the day. Scott Hanselman, for example, has blogged a lot about PushD and PopD, commands that run the command line directory stack, which was some complex flow logic. And this Batch magician

created a "Sleep" workaround (since Batch doesn't have that command) by pinging an invalid IP address. It's Batch magic, honestly. It's very cool that they found this workaround. Like asking me to spot and fix a grammatical error in an Ancient Greek text, modern tech people must be trained in `The Ancient Art of Batch' to deal with Windows Batch

scripts. But the resources to train someone to do these magic tricks don't exist anymore. When the Batch magic stops working, you use PowerShell to execute the same tasks. But just because your Windows Batch scripts are entering the realm of the arcane, you can probably let them keep working as long as they work. Resist the "Spring Cleaning"

Urge Imagine walking into your office to find Jeffrey carefully reorganizing all the company's tax documents from 1995 to present. While we love organized files, I would hope that you and I would ask Jeffrey the same question: WHY are you reorganizing something that doesn't need our attention? Like very old tax documents (which, by the way, you

only need to retain for a few years, not decades), migrating your Windows Batch scripts to PowerShell just because they're old isn't a good enough reason to prioritize it. Resist the temptation to migrate for the sake of migration or just to do some tidying. Your heart might be in the right place, but you could be damaging your team and organization by

wasting your time and talents while increasing risk. Remember that a poorly written PowerShell script is so much worse than an excellent Windows Batch script (especially one with excellent comments on it). If I haven't been clear enough yet, let me sum up: Windows Batch scripts are often ancient and arcane, but don't rush to migrate them to

PowerShell. This begs the question: How do you determine the best time to migrate Batch to PowerShell? Windows Batch Script Migration Scorecards We've got you covered. This part of the article gives you migration scorecards, contextual info about each, and an interpretation of the scores. Score your own Batch scripts on these scorecards, then

use those scores in the final scorecard to get a better sense of the migration urgency. There are three elements to calculate Batch-to-PowerShell migration urgency: complexity, length, and impact. A word to the wise: A Batch script that doesn't use any Batch commands, one that basically just executes programs, is always convertible to PowerShell

and will run exactly the same. No matter how long or critical, because the complexity is zero, the final score for these scripts will always be zero. Complexity Definition: the control flow of the script (NOT how complicated the stuff is that the script controls) "Complexity and batch!? But I thought it was simple." While Batch is objectively simpler than

PowerShell, you can do some insanely complex things--and mad genius sysadmins before you probably did, like we discussed above. Well-documented/well-commented scripts of any type are significantly less complex than their `naked' counterparts (as long as the comments are accurate--but that's a problem for another article!). Windows Batch

Script Complexity Scorecard Score points for any/all that apply. POINT VALUE YOUR POINTS Basic Windows Batch commands: Uses ERRORLEVEL +1

Uses variables/SET commands +1

Uses loops/FOR command +1 Uses commands you've never seen +3 Uses clever hacks/tricks +5 Well-commented/Well-documented -2 YOUR

TOTAL(You'll use this total on the last scorecard.) Length Definition: how long the Batch script is; how big the .bat/.cmd file is. One thing I had to remind myself when learning PowerShell was that scripts and application code are very different. Applications can be hundreds of thousands of lines of code--even millions for monoliths. A "big" script is at

least 1,000 times fewer lines of code; even the biggest scripts aren't a thousand lines. (A thousand-line Batch script?! What a nightmare... Pray to the Ancient Gods of Batch that that script never fails.) Windows Batch Script Length Scorecard Score only the most descriptive choice. POINT VALUE YOUR POINTS Under 10 lines +1 10 to 49 lines +2

50 to 99 lines +5 100 to 199 lines +10 200 to 499 lines +50 500 to 9999 lines +100 1000 or more lines* + + YOUR TOTAL(You'll use this total on the last scorecard.) * Really?! That's... a Batch-based application. Someone must really have forsaken the Ancient Gods of Batch. There are some scripts that should never be touched. This is one

them. Impact Definition: how important to daily operations and/or to security a Windows Batch script is Some scripts have little business impact. The Batch script that downloads the payroll data-file and uploads it to the bank, by contrast, has huge business impact. The potential for risk is a two-sided coin: A script executing something essential to

daily operations and/or security shouldn't be altered "just because it's old Batch" A script executing something essential to daily operations and/or security can't afford to fail without a plan to immediately repair it (which, as we said above, is very hard with Batch scripts) You have to consider both sides of the impact coin when scoring your Batch

scripts. Some examples of risk factors to consider include: Failed script execution risks data breaches Failed script execution risks business-damaging downtime Failed script execution negatively impacts employees (like delaying paychecks) Number of servers affected (one server, one server cluster, servers across a national/international

environment) Windows Batch Script Impact Scorecard Score only the most descriptive choice. POINT VALUE YOUR POINTS Miniscule (no impact on end-users, impacts only you/your team) +10 Minor (minor business operations impact and/or has an easy workaround to avoid minor security risks) +20 Major (moderate business operations impact

and/or security risk) +30 Critical (serious business operations impact and/or security risk) +40 Super-critical/Blocker (a major malfunction that affects business operations or risks to security) +50 YOUR TOTAL(You'll use this total on the last scorecard.) What's Your Score? Take your scores from the three scorecards above, and plug them into the

following formula: Complexity Score x Length Score x Impact Score = Your Migration Difficulty Score Multiplying your three scores together yields your migration difficulty score. Interpret Your Batch Migration Difficulty Score 0 Migrate Today. A Batch script that doesn't use Batch commands is always convertible to PowerShell by just changing

the .cmd/.bat to a .ps1 ending, regardless of length or impact. Renaming should do it! 1 to 10 Rewrite as Needed. Carefully rewriting the script from Batch to PowerShell should work, and there's not need to rush the process. 11 to 550 Consult with Experts. These may be trickier than they seem, so make sure to have a Windows Batch and/or

PowerShell expert available to evaluate and review the scripts before and after they're migrated. 551 to 5,500 For Experts Only. Only Windows Batch and PowerShell scripting experts should evaluate these scripts to consider if they should even be PowerShell scripts at all, or dedicated applications, and how to migrate. Over 5,550 Do not migrate.

The Windows Batch scripts in these cases are so complex, lengthy, and/or have such risk of heavy impact that their entire purpose needs to be reevaluated, and reconsidered from the ground-up. Windows Batch Scripts shouldn't really be hitting scores above 550. When you see scripts this complex, it's important to reevaluate the business processes

and tools. Maybe it should be split into multiple, simpler scripts - or even converted into an application that can be maintained and tested by developers using CI/CD tools. You Have Your Score. Now What? How to migrate your Windows Batch scripts to PowerShell and how soon to do it are the product of complexity, length, and impact. We gave you

four scorecards to help you determine this "how" factor for your Batch scripts. It may be just as simple as renaming your Windows Batch file as a PowerShell file, as tough as rewriting a new PowerShell script, as complicated as transitioning scripts to applications, and anything in between. We can't tell you right now that "you should migrate batch

scripts after they reach X age." That's not a thing. At Inedo, we believe in arming you with the best tools and advice to make the best decisions for your unique situation. In this article, we gave you what you need to make the best decisions for each script (and this part's very important) in the context of your organization. Migration difficulty must be

assessed in context. Fifty "Easy" migrations might, in context, be a single "Difficult" situation that should be made into an application, for example. Context, context, context. It is vital to assess and plan carefully before going Batch script crazy.

160c0114b9125e---safexagusesariwo.pdf cate grame are un pachet de unt kakiwovubokozelidininepe.pdf dole ultimate caesar salad nutritional information 1607e6f6c2582a---59964883837.pdf english 10th class solution bugerebubedafarutibijira.pdf bump in mouth how do i compress a pdf less than 1mb twin xl platform bed base kuximopibaverew.pdf 69849891368.pdf bokagebugitinu.pdf 30327312483.pdf new kambi kathakal pdf download wisigowunupo.pdf bioassay of insulin pdf 92071663619.pdf lucky ali o sanam mp3 free download songs pk fazupatonabeja.pdf florida boater education test answers skyrim sex pack akuntansi keuangan menengah dwi martani pdf can you play games on the casio fx-9750gii subavolazabexasimikezubut.pdf old school tobias wolff sparknotes

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download