Ivanti Automation (formally known as RES Automation) and PowerShell work very well together. By using PowerShell from within Ivanti Automation we are able to talk to any system that utilize a REST full API.
The Task for Powershell does only allow for all the screen output of a script to be placed in one Automation parameter. To divide this output into multiple parameters the data had to be splited in Automation or in Ivanti Identity Director.
For a recent project it is a requirement to change a date value to the EPOCH format. We need this EPOCH date format to automate the creation of a ticket in a Remedy system. The customer is using BMC Atrium Orchestration as a frontend to the Remedy system.
What is EPOCH Time?
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).
Why does EPOCH time start in 1970?
So no file can be created before 1970-01-01. … Unix was originally developed in the 60s and 70s so the “start” of Unix Time was set to January 1st 1970 at midnight GMT (Greenwich Mean Time) – this date/time was assigned the Unix Time value of 0. This is what is know as the Unix Epoch.
I’ve created a small PowerShell function to convert a Get-Date input to the EPOCH date/time format.
function ConvertTo-Epoch ([datetime]$InputEpoch) {
[datetime]$Epoch = '1970-01-01 00:00:00'
[int]$Ctime = ""
$Ctime = (New-TimeSpan -Start $Epoch -End $InputEpoch).TotalSeconds
return $Ctime
}
$a = ConvertTo-Epoch (get-date)
In this article I want to talk about managing a SQL 2012 Server with PowerShell from a remote computer. As I’ve mentioned in an earlier blog post PowerShell is becoming more and more important in the day to day task of a system administrator.
I am using PowerShell ISE as scripting application. It is a simple scripting tool but it does everything I need at this time to make my PowerShell work easy.
$fldr = "C:\users\robin\Documents\PowerShell\data"
$credential = Get-Credential
$credential.Password | ConvertFrom-SecureString | Set-Content "$fldr\adminpassword.bin"
$password = Get-Content "$fldr\adminpassword.bin" | ConvertTo-SecureString
$cred = New-Object System.Management.Automation.PSCredential("contoso\adminrobin", $password)
New-PSSession -Name SQL -ComputerName sql01.contoso.com -Credential $cred
Enter-PSSession -Name SQL
Last week I was busy building a new lab environment on my Hyper-V environment. My automated installation joined the machine to my LAB environment domain and disable the Windows Firewall. The only thing I forgot to include was enabling Remote Desktop. It was not posible to start a remote registry session, and I did not have my machine running that has the Hyper-V Manager installed.
The solution is to open a remote PowerShell sessie via the ServerManager.
Today I want to show you how to create a PowerShell instance that is all ready for managing a Citrix XenDesktop 7.1 environment.
We’ve all been there you want to check something quickly in your environment. You start up PowerShell, enter a command and you are presented with an error message that the command you just entered is not recognized by PowerShell.
We get this error message not because of a typo but because the Citrix Snap-ins are not loaded in this PowerShell session.
Recently I did some research for an Shared Hosted Desktop environment based on Citrix XenDesktop 7.1. The environment I did my research for consists of 40+ Remote Desktop Services servers, based on Windows 2012 R2. These servers are Citrix Provisioning Services target devices. Within Citrix XenDesktop we have published an Server OS Desktop, with the Machine Catalog, consisting of the aforementioned 40+ RDS servers. The end user will connect to this desktop after logging in to an Storefront portal.