Wednesday, 18 October 2017

Get-ScheduledTask does not return monthly, or monthly day of week triggers.

So having worked with the Task Scheduler Library in Windows over the last few weeks it's a real problem area of Windows

I've already mentioned the issue that deprecated features still appear in the user interface.

The next area to note is that the Get-ScheduledTask PowerShell cmdlet is not fully functional. If you create a scheduled task with a monthly trigger (or a monthly day of week trigger) this cannot be read using the cmdlet.

Instead of a fully fledged object like you would receive from the other trigger types you instead receive the base object.

MSFT_TaskTrigger

Enabled               : True
EndBoundary           :
ExecutionTimeLimit    :
Id                    :
Repetition            : MSFT_TaskRepetitionPattern
StartBoundary         : 2017-10-18T19:31:14
PSComputerName        :
CimClass              : Root/Microsoft/Windows/TaskScheduler:MSFT_TaskTrigger
CimInstanceProperties : {Enabled, EndBoundary, ExecutionTimeLimit, Id...}
CimSystemProperties   : Microsoft.Management.Infrastructure.CimSystemProperties

I was hoping that the limitation was with the PowerShell cmdlets however on checking it seems that the limitation is with the underlying WMI in the ROOT\Microsoft\Windows\TaskScheduler namespace.

The only option in this case is to parse the XML configuration files directly. Not pleasant.

Friday, 13 October 2017

An error has occurred for task 'name'. Error message: The following error was reported: 2147750704. When creating a scheduled task in Windows 2012 or above.

When you create a scheduled task in Windows you notice that the Send an e-mail and Display a message tasks are marked as "deprecated".


You can no longer create these task types and the following error is shown

"An error has occurred for task 'name'. Error message: The following error was reported: 2147750704".


I'm really not sure why Microsoft didn't remove the UI options, it seems strange to have gutted the functionality but leave the options in the user interface.

If you want to send an email you can schedule to Start a program and use the Send-MailMessage PowerShell cmdlet.


Monday, 2 October 2017

Document Azure tenants with Microsoft Live accounts or multi-factor authentication

Our network and cloud documentation tool XIA Configuration is getting a new update.

As our product runs as a Windows service customers have previously had issues when trying to scan an Azure environment by logging on with a Microsoft Live account or with two-factor authentication.

The new version will include a stand alone tool for scanning Azure tenants




The tool operates in a similar way to the standard Azure scan agent.




This will run interactively and display the standard Azure login dialog so that you can login using your normal credentials.



You can then save the output and import it directly into the XIA Configuration Server.



Friday, 29 September 2017

Importing modules fails for C#.NET application - file cannot be loaded because running scripts is disabled on this system.

When you're tying to import a PowerShell script into a C#.NET application you may see an error like this
File C:\Program Files\WindowsPowerShell\Modules\AzureRM\4.4.0\AzureRM.psm1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.

When you check the execution policy using Get-ExecutionPolicy it looks fine.



The issue here may be related to the application running in 32-bit mode, this has a different execution policy


Monday, 25 September 2017

The apply button of the PowerShell security descriptor dialog does not work as expected - Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell

When running the following command to modify the PowerShell security descriptor
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell

The following dialog is displayed.


Be aware that clicking the Apply button does not apply the security setting until either the OK or cancel button is clicked.

This behaviour can give confusing results when testing the access control lists.

Tuesday, 19 September 2017

Get-CimInstance PowerShell cmdlet doesn't have any methods

If you've moved from the Get-WmiObject to the new Get-CimInstance cmdlets you may find that these no longer have the methods available that you would have had when using Get-WmiObject.

This is because everything is being routed correctly though the WS-MAN protocol and the objects that are returned are not code and cannot be executed.

It's a simple work around - just pipe the object back to the Invoke-CimMethod cmdlet...

$printers = Get-CimInstance Win32_Printer
$descriptor = $printers[0] | Invoke-CimMethod -MethodName GetSecurityDescriptor

Monday, 18 September 2017

Get-Printer StartTime and UntilTime

The Windows PowerShell Get-Printer cmdlet provides a start and finish time for printer availability but confusingly this value is returned as an integer value.



More confusingly this is stored as a value of minutes from midnight GMT so if you print server is in GMT -5 and has a available from time of midnight you'll see the StartTime of 300.

If you'd like to convert the time to a DateTime that is more understandable that reflects what is seen in the UI try the following



$baseTime = [System.DateTime]::MinValue.AddDays(1)
$baseTime = $baseTime.AddHours([System.TimeZoneInfo]::Local.BaseUtcOffset.TotalHours)
$baseTime = $baseTime.AddMinutes(150)