Powershell remoting and page file - powershell

I wrote a powershell script that connects to a remote machine with the intent of executing a software rollout on said machine. Basically it connects, maps a drive, copies the rollout from the mapped drive to the target machine, then executes a perl script to install the rollout. If I do those steps manually everything works fine. When I try using my script, the perl script fails on the remote machine saying, "The paging file is too small for this operation to complete".
Can someone explain the considerations I need to take into account when operating remotely? I've tried monitoring memory usage and I don't see anything out of the ordinary. Is the page file OS wide or is there some type of per user configuration my script should be setting when it connects?
I can post snippets of my script if needed, but the script is 426 lines so I think it would be overwhelming to post in its entirety.

I found that the remote shells are managed differently than logging onto the box and executing a powershell session. I had to increase the maximum amount of memory available using one of the commands below:
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024
winrm set winrm/config #{MaxMemoryPerShellMB="1024"}
The default is 150MB which didn't cut it in my case. I can't say that I recommend 1GB, I'm just a developer. I tried upping it until I found what worked for me.

I tried this code to run the puppet client as an administrator but the framework still complains with "Access Denied"
Exe (C:\Users\lmo0\AppData\Local\Temp\Microsoft .NET Framework 4 Setup_4.0.30319\Windows6.1-KB958488-v6001-x64.msu) failed with 0x5 - Access is denied. .
using System;
using System.Diagnostics;
namespace RunAsAdmin
{
class Program
{
static void Main(string[] args)
{
Process proc = new Process();
Process p = new Process();
p.StartInfo.FileName = #"powershell.exe";
p.StartInfo.Arguments = #"invoke-command -computername vavt-pmo-sbx24 -ScriptBlock {&'C:\Program Files (x86)\Puppet Labs\Puppet\bin\puppet.bat' agent --test --no-daemonize --verbose --logdest console}";
p.StartInfo.Verb = "runas";
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
p.Start();
while (p.HasExited == false) {
Console.WriteLine(p.StandardOutput.ReadLine());
}
Console.ReadLine();
p.WaitForExit();
p.Close();
}
}
}

Related

Need assistance modifying a PowerCLI script

I was wondering if someone could please help with the following query. We are using the following script to enable Virtualization Based Security on a per VM level.
https://communities.vmware.com/t5/VMware-PowerCLI-Discussions/Turn-on-Virtualization-based-security-...
The script is running from within VMware Realize Automation / Orchestration in order to enable VBS as part of an specific workflow. The modified script for vRA/vRO is below.
The issue that I am having is that VBS can only be enabled when the VM is powered off, in some cases the workflow takes a little longer to run and by then the VM is running already which will make the task (script) to fail.
That being said, I was looking for some way to improve the script a little bit perhaps by adding something to power off the VM if it's running then execute the code in the script and then bring the VM back on. I feel that with something like this hopefully we will make sure that VBS is enabled when the VM is not running and once VBS is enabled it will turn on the VM to proceed. I have unsuccessfully tried to modify the code but I can't find a way to stop and start the VM successfully. Can someone please help?
Thank you
// Input: inputProperties from vRA
var enableVBS = inputProperties.customProperties.enableVBS
if (enableVBS == "true") {
var name = inputProperties.resourceNames[0]
var vms = VcPlugin.getAllVirtualMachines(null, name)
vm = vms[0]
var bootOpts = new VcVirtualMachineBootOptions()
var flags = new VcVirtualMachineFlagInfo()
var spec = new VcVirtualMachineConfigSpec()
bootOpts.efiSecureBootEnabled = true;
flags.vbsEnabled = true;
flags.vvtdEnabled = true;
spec.firmware = VcGuestOsDescriptorFirmwareType.efi;
spec.nestedHVEnabled = true;
spec.bootOptions = bootOpts;
spec.flags = flags;
vm.reconfigVM_Task(spec)
}

Unable to automate the migration process using Task Scheduler and SharePoint cmdlet “MigrateUserAccount”

Unable to automate the migration process using Task Scheduler and SharePoint cmdlet “MigrateUserAccount” getting error “You cannot call a method on a null-valued expression”
$spFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local
$spFarm.MigrateUserAccount("$from\$name", "$to\$name", $false)
When I run the PowerShell script using the “SharePoint 2010 Management Shell” it is running and the output is successful, but when I configured the PowerShell script in Task scheduler the script is running but it throws error like “You cannot call a method on a null-valued expression”
Below screenshot displays that task scheduler is running in high privileges.
enter image description here
enter image description here
And this task has been created using the service account who administration access to this servers and added to “db_owners” in sqldatabase aswell.
Server Architecture
Web Front End 1
Web Front End 2
Application Server 1
Application Server 2
Database Cluster Node1
Database Cluster Node2
If this is all on one line...
$spFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local $spFarm.MigrateUserAccount("$from\$name", "$to\$name", $false)
...then $spFarm will not have been defined when the MigrateUserAccount function is invoked.
You'll either need to put a semicolon between the two statements, or put them on separate lines like so:
$spFarm = [Microsoft.SharePoint.Administration.SPFarm]::Local
$spFarm.MigrateUserAccount("$from\$name", "$to\$name", $false)

Installing an exe with Powershell DSC Package resource gets return code 1619

I'm trying to use Powershell DSC's Package resource to install an exe... Perforce's P4V to be specific. Here's my code:
Configuration PerforceMachine
{
Node "SERVERNAME"
{
Package P4V
{
Ensure = "Present"
Name = "Perforce Visual Components"
Path = "\\nas\share\p4vinst64.exe"
ProductId = ''
Arguments = "/S /V/qn" # args for silent mode
LogPath = "$env:ProgramData\p4v_install.log"
}
}
}
When running this, this is the error Powershell gives me:
PowerShell provider MSFT_PackageResource failed to execute Set-TargetResource functionality with error message: The return code 1619 was not expected. Configuration is likely not
correct
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
+ PSComputerName : SERVERNAME
According to documentation, return code 1619 means the MSI package couldn't be opened. However, when I manually log in to the machine and run "\\nas\share\p4vinst64.exe /S /V/qn", the install works flawlessly.
Does anyone know why this is failing? Alternately, can anyone tell me how to troubleshoot this? I pasted all the error information I got from the terminal, my log file (p4v_install.log) is a 0 byte file, and there are no events in the event viewer. I don't know how to troubleshoot it any further!
EDIT: I should note that I also tried using the File resource to copy the file locally, and then install it from there. Sadly, that met with the same result.
Daniel over at the Powershell.org forums was able to figure this out for me.
The P4V InstallShield setup wrapper puts the MSI file into wrong path if you execute as LocalSystem.
I’ve managed to develop a Configuration that works, see below. The key is the /b switch here which puts the MSI file into a defined location. I’ve added ALLUSERS=1 to get the shortcuts visible to all users and REBOOT=ReallySuppress to avoid a sudden restart (which will happen otherwise).
Configuration PerforceMachine
{
Package P4V
{
Ensure = "Present"
Name = "Perforce Visual Components"
Path = "C:\My\p4vinst64.exe"
ProductId = ''
Arguments = '/b"C:\Windows\Temp\PerforceClient" /S /V"/qn ALLUSERS=1 REBOOT=ReallySuppress"' # args for silent mode
}
}
Well, what happens here is that the package gets installed (not tested with p4vinst64.exe yet! So, not sure why it says pack cannot be opened as the error) but since you did not specify a ProductID value, the verification at the end of install fails. That is the error you are seeing. The Package resource is no good for installing .exe packages or even MSIs with no ProductID represented as a GUID.
You can use the WindowsProcess resource instead.

Return code of scheduled task prefixed with 0x8007000 in list view, registered as 0 in the event log

I am currently trying to setup monitoring of windows scheduled tasks in Zabbix. It seemed easy enough to just monitor the Microsoft-Windows-TaskScheduler/Operational event log filtered by 201 events and regexing on the return code, but when I started simulating errors to test the monitoring, nothing happened.
It turns out that all our windows 2012 servers always log "return code 0" in the event log, even though it actually, sort of, displays it correctly in the Task Scheduler list view. When I say "sort of", it's because the "Last Run Result" actually displays 0x80070001 if the exit code of the program run by the scheduled task is 1.
I have spend a lot of time tweaking the settings, like user account, Run only when user is logged on, Run whether user is logged on or not, setting path on the action, Run with highest privileges, Configure for Vista/7/2012, etc. Nothing helped.
Finally I did some testing on my local machine, Windows 7, and a 2008R2 server, both of which just worked as expected.
The specific task I was testing ran a PowerShell script, using -Command so that it properly propagates the exit, but to rule out any PS issues I also tested with a batch file containing "exit 1" and finally with a small C# console program, that just returns whatever you supply on the command line.
PS, batch and console program all work fine on 7 and 2008, but they all fail in the same manner on 2012.
I've google this to death, but keep coming up short. Apparently 0x80070005 and other similar error codes are have some meaning, but that's not what happens in my case. In my case it seems that my exit code is bitwise or'ed with 0x80070000.
I should note that in all the cases, even 2012, the program started by the task, actually executes and run to the end, it's just the exit code which is handled weirdly.
Following is the output from the test runs:
From Powershell (my shell writes :( if $LASTEXITCODE > 0 ):
54 :( .\ExitCodeTest.exe 1
55 :( $LASTEXITCODE
1
56 :) .\ExitCodeTest.exe 10
57 :( $LASTEXITCODE
10
Windows Server 2008 R2 Standard:
Last Run Result (from list view): 0xA
Event 201 from event log Microsoft-Windows-TaskScheduler/Operational:
Task Scheduler successfully completed task "\ErrorTest" ,
instance "{b67a26cf-7fd8-461a-93d9-a5e48e72e558}" ,
action "D:\Tasks\ExitCodeTest.exe" with return code 10.
Windows Server 2012 Datacenter (notice that the return code in the event log is 0):
Last Run Result (from list view): 0x8007000A
Event 201 from event log Microsoft-Windows-TaskScheduler/Operational:
Task Scheduler successfully completed task "\error test" ,
instance "{2bde46b8-2858-4772-a7ec-d66b29d893a6}" ,
action "D:\Tasks\ExitCodeTest.exe" with return code 0.
Source for ExitCodeTest.exe:
static void Main( string[] args )
{
int exitCode = 0;
if ( args.Length > 0 )
{
exitCode = Convert.ToInt32( args[0] );
}
Environment.Exit( exitCode );
}
Please help, I am at my wits end.
Thanks,
John
(this is NOT an answer, but StackOverflow is refusing to let me add comments - when I click 'add comment', browser scrolls to top of page :-/)
You may be misinterpreting the Last Run Result column. According to Wikipedia (http://en.wikipedia.org/wiki/Windows_Task_Scheduler), LRR values of 0, 1 and 10 are common. Ignore the 0x8007 prefix - this just indicates a WIN32 error code transformed into an HRESULT (http://msdn.microsoft.com/en-us/library/gg567305.aspx).
Try running the test and forcing an exit code of something other than 1 or 10 to see if this influences LRR.
This does not explain of course why action return code is 0 in 2012. Error code 10 is defined as 'environment is incorrect'. Could it be that 2012 server does not want to run 32bit executable?
One other suggestion (and I'm a little out of my depth); according to (http://msdn.microsoft.com/en-us/library/system.environment.exit(v=vs.110).aspx): "Exit requires the caller to have permission to call unmanaged code. The return statement does not.". Might be worth re-compiling ExitCodeTest as follows:
static int Main(string[] args)
{
int exitCode = 0;
if ( args.Length > 0 )
{
exitCode = Convert.ToInt32( args[0] );
}
return exitCode;
}
I'm seeing a similar issue on Server 2012 with a batch file that looks like it succeeds, shows a return value of 0 in event log, but a Last Run Result of 0x80070001.
I see MSFT has a hotfix available for Server 2012 which might address this issue:
http://support.microsoft.com/kb/3003689
I had this problem and fixed it this way.
Instead of calling a batch file move the commands into the actions section of the scheduled task.
I realize this may not work for you as some batch files are long.
I suspect it has to do with circumventing security on a scheduled task -- if you can change the batch file then you could get a scheduled task to run as the identity without windows being the wiser.

Why did SQL Server Management Studio 2008 command-line switches stop working?

I've always relied heavily on Windows shortcuts to SSMS that include command-line switches allowing me to quickly open up a specific database on a specific server. For example
Ssms.exe -S 123.123.123.123 -U sa -P goodpassword -d DbName
or
Ssms.exe -S . -E -d DbName
These suddenly stopped working. I get this error from SSMS:
Failed to create new SQL Server script.
Object reference not set to an instance of an object. (AppIDPackage)
Program Location: at Microsoft.SqlServer.Management.UI.VSIntegration.
AppIDPackage.AppIDPackage.OpenConnectionDialogWithGlobalConnectionInfo()
I can still launch SSMS without the command-line switches, and then manually establish the connections. Some command-line switches still work, for example
ssms.exe -nosplash
works fine.
I get the same error with any combination of the -S, -E, and -d command-line switches. It doesn't matter if I'm pointing to a valid server or database or not, or if my login credentials are good or not. I can point to the older version of SSMS and it works fine, but not the 2008 version.
This post on MSDN's forums is all I've found online, but MS hasn't been very helpful on this thread.
Any ideas how I might start to fix this? I work with a lot of different databases on different servers, and I really rely on these shortcuts.
I've thrown the DLL in question at reflector and it's given me back the code at the bottom of this post, sadly there's nothing immediately obvious in the code that makes it easy to work out why it's stopped working for you (wouldn't it be nice if Microsoft shipped debug symbols with anything they produce that's written against the CLR?).
There are a couple of places where the code makes me wonder if you might have a corrupted "recently used servers" list or something similar, perhaps you could try following the steps listed in this question to clear them out and see if that helps.
private void OpenConnectionDialogWithGlobalConnectionInfo()
{
if ((ServiceCache.GlobalConnectionInfo != null) && (ServiceCache.GlobalConnectionInfo.Count != 0))
{
try
{
using (ConnectionDialog dialog = new ShellConnectionDialog())
{
IDbConnection connection;
dialog.ImportRegisteredServersOnFirstLaunch = true;
dialog.AddServer(new SqlServerType());
UIConnectionInfo connectInfo = ServiceCache.GlobalConnectionInfo[0].Copy();
if (dialog.TryToConnect(this.PopupOwner, ref connectInfo, out connection) == DialogResult.OK)
{
this.ScriptFactory.CreateNewBlankScript(ScriptType.Sql, connectInfo, connection);
}
}
}
catch (Exception exception)
{
ExceptionMessageBox box = new ExceptionMessageBox(new ApplicationException(SRError.FailedToCreateNewSqlScript, exception));
box.Caption = SRError.MessageBoxCaption;
box.Show(this.PopupOwner);
}
}
ServiceCache.GlobalConnectionInfo = null;
}
The ObjectExplorer window must be open. Don't hide.
I solved my problem this way :)
Works fine like this:
sqlwb.exe -S . -E -d dbName
I'm using SSMS2008 against a SQL2005 database, and the ssms command line works fine here.
This is the version info produced by the SSMS About dialog:
Microsoft SQL Server Management Studio 10.0.1600.22 ((SQL_PreRelease).080709-1414 )
Microsoft Data Access Components (MDAC) 6.0.6001.18000 (longhorn_rtm.080118-1840)
Microsoft MSXML 2.6 3.0 5.0 6.0
Microsoft Internet Explorer 8.0.6001.18813
Microsoft .NET Framework 2.0.50727.3074
Operating System 6.0.6001
There are several sources (MSSqlTips, and here) that state the command line arguments are available on sqlwb.exe. Yet the Books Online page for ssms states that the options are available on ssms.