I would like to benchmark the response time of a site as well as simulate a load via the windows command line (WIN+R)
Is this possible?
What is the windows equivalent of this linux command:
$ ab -n 1000 -c 5 http://yourpage.com
Extra Credit for Powershell 3 Equivalent
There is no equivalent built-in PowerShell cmdlet that does this. I see from ab's man page that your command sends 1000 requests, 5 at a time to the web server. You could roll your own solution in PowerShell using either the System.Net.WebClient or System.Net.HttpwebRequest classes, and implement concurrency with PowerShell jobs, parrallel for-loop workflows or asynchronous pipelines, however there are already solutions pre-built for this task like jmeter.
Related
Whether month end process can be automated in progress bases applications like nessie? I already searched for it and I think maybe it can done by scheduling it through background jobs.
Scheduling jobs is a function of the OS or of 3rd party applications that specialize in such things (generally used in large enterprises with IT groups that obsess over that kind of stuff).
If you are using UNIX then you want to look into "cron".
If you are using Windows then "scheduled tasks".
In any event you will need to create a "wrapper" script that properly sets the background job environment and launches a Progress session. If you are using Windows you should be aware that a batch process is "headless" and that unless your batch process is doing something very strange it will not be using GUI components -- so you should probably run _progres.exe rather than prowin32.exe.
A generic (UNIX) example:
#!/bin/sh
#
DLC=/usr/dlc
PATH=$DLC/bin:$PATH
export DLC PATH
_progres -b -db /path/dbname -p batchjob.p > logfile 2>&1 &
(That is "_progres" with just 1 "s" -- this is from the days when file names were restricted to 8 characters on some operating systems.)
Windows is very similar:
# echo off
set DLC=c:\progress
set PATH=%DLC%\bin;%PATH%
_progres.exe -b -db \path\dbname -p batchjob.p > logfile 2>&1
But there are a lot of "gotchyas" with Windows. If, for instance, you run a job using a login-id that might actually login then you will have the problem that on logout all the scheduled tasks will be "helpfully" killed by the OS. Aside from stopping your job when you probably don't want it to this may have other negative side effects like crashing the db. To get around that problem on Windows you either create a "service account" that never logs in or use 3rd party scheduler that runs jobs "as a service".
We have some .net applications running on a server that run powershell scripts. Is there a setting where we can log every single powershell command run on that machine, without modifying our existing applications? I already tried start-transcript . That command only captures the commands run in the current session.
I believe Microsoft calls what you're after "Over the Shoulder Transcription". It's described here, and will be available in WMF5.
I'm a nub scripter and am trying to write a really simple script to taskkill 2 programs and then uninstall 1 of them.
I wrote it in Powershell and stuck it in SCCM for deployment...however every time I deploy it, it's not running the last line to uninstall the program.
Here's the code:
# Closing Outlook instance
#
taskkill /IM outlook.exe /F
#
# Closing Linkpoint instance
#
taskkill /IM LinkPointAssist.exe /F
#
# Uninstalling Linkpoint via uninstall string if in Program Files
#
MsiExec.exe /X {DECDCD14-DEF6-49ED-9440-CC5E562FDC41} /qn
#
# Uninstalling Linkpoint via WmiObject if installed manually in AppData
Get-WmiObject -class win32_product -Filter "Name like '%Linkpoint%'" | ForEach-Object { $_.Uninstall()}
#
Exit
Can someone help? SCCM says the script completes with no error and I know it's able to execute it since the taskkills work...but it's not uninstalling the program.
Thanks in advance for any input.
So, SCCM is running this script, and nothing in the script is going to throw an error.
If you want to throw an error which SCCM can return to know how the deployment went, you need to add an extra step.
$result = Get-WmiObject -class win32_product -Filter "Name like '%Linkpoint%'" | ForEach-Object { $_.Uninstall()}
if ($result.ReturnValue -ne 0){
[System.Environment]::Exit(1603)
}else
{
[System.Environment]::Exit(0)
}
I see a lot of these kinds of questions come through on SO and SF: Someone struggling with unexpected behavior of an application, script, or ConfigMgr and very little information about the assumptions I can make about their environment. At that stage, it would typically be days of interaction to narrow the problem to a point where a solution is possible.
I'm hoping this answer can serve as a reference for future such questions. The first question to OP should be "Which of these 9 principles are you violating?" You could think of it as a sort of Joel Test for ConfigMgr application packaging.
Nine Steps to Better ConfigMgr Application Packages
I have found that installing and uninstalling applications reliably using ConfigMgr requires carefully sticking to a bunch of principles. I learned these principles the hard way. If you're struggling to figure out why an application is not working right under ConfigMgr, odds are that you will answer "no" to one of the following questions.
1. Are you testing the entire lifecycle?
In order to have any hope of reliably managing an application you need to test the entire lifecycle of an application. This is the sequence I test:
Detect: make sure the detection script result is negative
Install: install the application using your installation script
Detect: make sure the detection script result is positive when run
Uninstall: uninstall using your uninstallation script
I run this sequence repeatedly making tweaks to each step until the whole sequence is working.
2. Are you testing independently of ConfigMgr first?
Using ConfigMgr to test your application's lifecycle is slow and has its own ways of failing that can mask problems with your application package. The goal, then, is to be able to test an application's installation, detection, and uninstallation separate from but equivalent to the ConfigMgr client. In order to achieve that goal you end up with three separate scripts for each application:
Install-Application.bat - the entry point for your installation script
Detect-Application.ps1 - the script that detects whether the application is install
Uninstall-Application.bat - the entry point for your uninstallation script
Each of these three scripts can be invoked directly by either you or the ConfigMgr client. For applications installed as system you need to use psexec -s to invoke scripts in the same context as ConfigMgr (caveat).
3. Are you aware of context?
Installers can behave rather differently depending on the context they are invoked in. You need to consider whether an application is installed for a user or the system. If it is installed for the system, when you test independently of ConfigMgr, use psexec -s to invoke your script.
4. Are you aware of user interaction?
An installer can also behave rather differently depending on whether a user can interact with it. To test a script as system with user interaction, use psexec -i -s.
5. Did you match ConfigMgr to the tested context and user interaction?
Once you have the full lifecycle working, make sure you select the correct corresponding options for context (installed for user vs. system) and interaction (user can interact with application, or not). If you don't do this, the ConfigMgr client will be installing the application different from the way you tested, so you really can't expect success.
6. Are you aware of the possibility of application detection context mismatch?
The context that detection scripts run in depends on whether the application is deployed to users or systems. This means that in some cases the installation and detection contexts won't matched. Keep this in mind when you write your detection scripts.
7. Have you structured your scripts so that exit codes work?
ConfigMgr needs to see exit codes from your installation and uninstallation scripts in order to do the right thing. Installers signal failure or the need to reboot using exit codes. In order for exit codes to get to the ConfigMgr client you need to ensure that your install and uninstall scripts are structured correctly.
for batch scripts, use exit /b %errorlevel% to pass the exit code of your executable out to the ConfigMgr client
for PowerShell scripts, this is the only way I have seen work reliably
8. Are you using PowerShell scripts for detection?
ConfigMgr has a nice user interface for checking things like the presence of files, registry keys, etc as a proxy for whether an application is installed. The problem with that scheme is that there is no way to test application detection separately from and equivalent to the ConfigMgr client. If you want to test the application lifecycle independent of the ConfigMgr client (trust me, you want that), all your detection must occur using PowerShell scripts.
9. Have you structured your PowerShell detection scripts correctly?
The rules ConfigMgr uses to interpret the output of a PowerShell detection script are arcane. Thankfully, they are documented.
I'm having a weird problem where, when doing a lot of playing in the Powershell commandline, at some point it will stop executing any commandline application like cmd.exe or more.com, but will continue to execute Powershell functions and such. I can open up a new Powershell window
The situation
I'm using Powershell Community Extensions
I have a Powershell profile
I seem to encounter this when I'm trying to debug a script I'm writing (more on that later)
The problem by example
Normally I should be able to run ping and see normal output like this:
PS> ping google.com
Pinging google.com [74.125.227.78] with 32 bytes of data:
Reply from 74.125.227.78: bytes=32 time=30ms TTL=49
Reply from 74.125.227.78: bytes=32 time=38ms TTL=49
Reply from 74.125.227.78: bytes=32 time=31ms TTL=49
Reply from 74.125.227.78: bytes=32 time=32ms TTL=49
Ping statistics for 74.125.227.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 38ms, Average = 32ms
PS>
However, when I'm experiencing this problem, the PS prompt just returns immediately:
PS> ping google.com
PS>
I can verify in Task Manager that ping is not running during this time. Furthermore, for programs which should modify files on the filesystem (like takeown.exe or GnuWin32's wget.exe), the modifications do not occur. As far as I can tell, the command does not run at all.
This happens with every non-Powershell commandline app I can think of (more.com, GnuWin32's less.exe, ping.exe, cmd.exe, python.exe from the official Python distribution, StrawberryPerl's perl.exe, etc).
I can still run any Powershell function, cmdlet, or alias. Furthermore, I can run non-commandline apps like notepad.exe.
The (possible) culprit: my script
I have been trying to write a PS script over the last few days, when this problem started to crop up. It's too long to paste here (400 lines at the moment), but I've uploaded it to pastebin if you want to see it. (Currently not working very well.)
Right now I'm dealing with some permissions problems in the WinPE-AddExplorer function in that script, so a lot of the time I'm Ctrl-C'ing while that function is running... could something in there be causing the problem?
I had this exact problem. I'm guessing you're using Powershell V2. Please see this bug report (https://connect.microsoft.com/PowerShell/Feedback/Details/665809). Supposedly fixed in Powershell v3. (I have not seen this problem in v4 using the same script that does not work in v2)
The workaround is to put "[GC]::Collect()" in your loop that writes to the console.
Here are a few thoughts:
Try running PowerShell with -NoProfile. Import the PSCX module and run your script
Try running PowerShell without the PSCX module (adjust your profile script to NOT import, if necessary), then try running your script
Try not to use 3rd party modules in general
On another note, I had a look through your script, and nothing jumps out at me that would be permanently adjusting your PowerShell session. To debug this issue, try to think of any permanent, environmental changes that your profile (or your script) might be making. The developers of PSCX may or may not have code that makes permanent adjustments to your PowerShell environment also.
Use traditional troubleshooting techniques to help zero in on what area (your script, PSCX, or your profile) is causing you this problem.
TASK TO BE ACCOMPLISHED:
To schedule a perl script which is executed on a specific time / day in a week
THINGS I HAVE DONE:
In a schedule Tasks, I have created a new Task by which the Task will call a batch file with below contents
cd "DRIVE\FOLDER\Hummingbird\Connectivity\14.00\Exceed\"
ABCD.xs
cd mDrive/bin
perl baseline.pl -publish -location XXX -email
THINGS NOT WORKING FOR ME / CAUSING THE ISSUE:
Wen I run the scheduler, the prompt opens up the ABCD.xs exceed file window seperately file but the below commands are executed in the command pronpt itself
EXPECTED OUTPUT:
I want the commands
cd mDrive/bin
perl baseline.pl -publish -location XXX -email
to be executed in the exceed window
Any kind of solution wud be great
Thanks in advance.
Haresh
Sounds like you need to start getting into either SendKey stuff (Win32 packages) or else look into writing Exceed/Hummingbird scripts and just executing those.
Some other things to look into... does the remote server have a telnet or ssh server running? Or are there other methods of executing code on the remote server?
For example, my work's mainframe is accessed via a Hummingbird terminal emulator, but I can also telnet to the mainframe and execute commands as well as FTP batch job directly into the JES spool. So when I execute things on the mainframe by way of my PC (Perl scripts, etc.), I don't even fool with Hummingbird.
Good luck...