I'm looking creating some health check scripts via Powershell for my environments. In my health check script I'm including the running status of my IIS Windows Services, and the Worker Process status. However, I can't figure out how to identify if my Appdomain has been unloaded. And if it has, what time was it unloaded.
FYI, the solution at How to check if AppDomain is unloaded? doesn't quite fit the bill. Looking into my own application log is another alternative, but I'm hoping there a way to check that by inspecting the worker process via Powershell or something.
My application is running on Windows Server 2012 R2 and IIS 8.5, and my health check scripts are using Powershell v4.0.
Related
This might be a very basic question. I have FileWatcher script in windows powershell which I want to run always so that it keeps watching a particular location for files. when I run it from Windows Powershell IDE its run perfectly fine. I understand that I can schedule a task in windows task scheduler for that but what's happening is that the task runs and then comes back in "Ready" status. This is NOT working. I think it should be in "Running" state always. I might be missing something. Please kindly help with your valuable suggestions.
You can do this with TaskSchedule…
Running PowerShell scripts as a “service” (Events: Prologue)
but this is also what permanent Event Subscriptions are for or setting up as user10675448 suggest, make it a real service.
How to run a PowerShell script as a Windows service
Windows PowerShell - Writing Windows Services in PowerShell
This article presents the end result of that effort: A novel and easy
way to create Windows Services, by writing them in the Windows
PowerShell scripting language. No more compilation, just a quick
edit/test cycle that can be done on any system, not just the
developer’s own.
There is also this approach...
PowerShell and Events: Permanent WMI Event Subscriptions
Unlike the temporary event, the permanent event is persistent object
that will last through a reboot and continue to operate until it has
been removed from the WMI repository.
There are multiple ways of setting up the WMI events and I will be
covering 3 of those ways (as they deal with PowerShell) in this
article.
I have a Powershell script that puts a Windows 2012R2 IIS(v8.5) Web server in "maintenance mode" by stopping a site and its associated app pool. (Stop-WebAppPool and Stop-Website cmdlets). However, if I run iisreset or reboot the server, that site and app pool are put back in a started state automatically.
The Start Mode on the app pool is set to "OnDemand".
"Preload Enabled" is set to False on the site.
Here's the interesting part. If I manually stop the site/pool using the IIS Mgmt Console, the stopped state "survives" an iisreset or server reboot. So, there seems to be something fundamentally different between what the console does and what powershell/code does.
I also tried using appcmd.exe commands instead of the PS cmdlets, same thing: Site and pool were automatically started after reset or reboot.
Has anyone experienced this? Any suggestions. I need this site to remain stopped after an iisreset or reboot so that it doesn't become live while performing maintenance.
Its a pretty basic site, so I've thought about just deleting and re-creating, but that seems a pretty extreme measure. Hoping somebody has a less intrusive method.
Here is a general description of the issue which I cannot solve:
We have a WindowsServer 2008 R2 system that is used to running the install of our product(using powershell script), and then the Powershell script calls the .exe of our UI test automation tool (Ranorex).
The install of the product works fine, but the UI automation portion only runs if some is physically logged in via remote desktop.
If the remote desktop session is closed (but the programs continue to run..so user is technically logged in), the UI automation portion will NOT run.
The options I selected on the General tab of the job are:
-Run only when the user is logged in;
-Run with highest privileges;
Any ideas on from anyone who has had this issue and got it to work would be extremly helpful.
Thanks,
Eric
UI operations are usually in suspended state when a user is disconnected from an RDP session. Use a tool like VNC or equivalent where you have access to the main console for these UI operations to remain active.
I am working on an automated deployment process for a web application. The deployment will need to:
Deploy DB changes to database using sqlpackage.exe
Deploy reporting services reports to the reports server using the web service
Deploy web app to web server(s)
Deploy fonts for reports
among other things
The first two are reasonably straightforward to run from the web server, as the web service and db are contactable, and the tools to deploy run over the network.
From reading it appears that powershell remoting should be the way to go, and internally this would not be a problem. However when deploying to production, this will be being carried out in a datacentre, where the machines (2web, 1db) are not on a domain at all. I'd like to come up with a generic process that can run both internally and externally with the appropriate configuration. Powershell remoting, with machines not in a domain appears to require a fair bit of configuration using https etc., as NT credentials can't be validated.
Should I battle out configuring powershell remoting, or would configuring this to just use psexec to execute a powershell script directly on the remote machien, copying the deployment artifacts to a drop folder on the remote machine be the best way to go?
psexec seems to "just work". It appears powershell remoting comes with a lot more pain.
Why not use psexec then? You can restrict it's role to just getting you on to the remote machine, and not let it infect your scripts. I have not attempted to get ps remoting working on a non-domain, but it general I have found it to be fairly high effort to get going. Psexec, as you say, can often be simpler.
Excuse the peddling, but the open source framework I helped build called PowerUp essentially does all this for your. It uses a model in which the powershell (well psake) scripts can move execution to another machine by calling a specific function. This can either be done with powershell remoting or psexec - you wouldn't need to change the script, it just requires a setting per environment to say which you would like to use.
Check other the sample at https://github.com/AffinityID/PowerUpSamples/tree/master/SimpleWebsite.
Hopefully that shows you enough, but if not let me know and we can go into more detail.
I'm writing a perl script for a website, and I need to be able to control VirtualBox via the website. I'm not sure where to start, or if I'm even trying to debug in the right area, but here goes.
My server is running IIS7 on Windows Server 2008 R2. I'm also running 2 virtual machines through the vboxmanage command line interface. These VMs are running under SERVER\administrator.
When I open my website, it requests a login. I login to the website as SERVER\administrator and click a link that calls my script using an xmlhttprequest. Now, normally, it doesn't matter what user I run these as, but with vboxmanage, if I run the command as a different user, the list of VMs is different. I tried whoami, which returned SERVER\administrator, but %DOMAINNAME%\%USERNAME% returns the domain that the server is connected to as dommainname and SERVER$ as the username. The vboxmanage command then fails.
On the website, impersonation is turned on. When I turn impersonation off, the whoami request changes to be iis apppool\website. Any ideas on how to get around this?
As a final note, I've thought about using runas, but since it prompts for a password, there's no way to call it through scripting (and that would be a poor security decision, I'd imagine).
This is an oft recurring, well-known and well-solved problem. Instead of having one big program dealing with requests from the Web and managing the VM (strong coupling), separate the concern and write two programs, each doing exactly one task.
The user facing program running in the Web server context can continue with limited privileges. The VM manager is a stand-alone program running with the necessary admin privileges, either repeatedly from the scheduler or as daemon/service.
Have the first communicate with the second over a message-queue.