A few weeks ago, I wrote a post about using PowerShell for logging script outputs and mentioned there’d be a part two. So here we go, finally. PowerShell logging is great for keeping track of data, but log files can quickly get too big. This makes it hard to find what you need or manage storage. With a simple script, you can split logs into separate files when needed. $logPath = "c:\Scripts\NICPingCheck.log" #Check if old log files exist and delete them if (Test-Path "$logPath.old") { Remove-Item "$logPath.old" -Force Write-Host "Old log file removed." } else { Write-Host "No old log file found to remove." } #Rename the current log file to .old if (Test-Path $logPath) { Rename-Item -Path $logPath -NewName "$logPath.old" -Force Write-Host "Current log file renamed to .old." } The script starts by deleting any files ending in .old. Next, it renames the current log file to add .old, so you al...
PowerShell is one of the most powerful tools in an administrator's toolbox, and I use it daily. The more I do with PowerShell, the more I need to record my script and save my script output as reference or proof of the changes made. For example, when did that condition-based automation fire, and what did it do, or what data did you update from that data extract from HR against AD? PowerShell provides several options, and here are my favorites. Write-Host The simplest option is the "Write-Host" command, which returns the output to the command window. This is great for returning simple values; you can watch as the script runs. By including the variable after the write host command, you can print its value at that point in the code for reference- $timestamp = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss") $message = "Logging Blog" Write-Host "$timestamp - $message" Typically, this wouldn't record the output anywhere other than i...
With Broadcom's recent licensing changes for VMware, I decided to change the hypervisor for my home lab. After evaluating several freely available options likely to work in an enterprise environment, I chose the XCP-ng/Xen Orchestra solution. When reviewing XCP-ng as a solution, it appears to be the closest to running VMware while maintaining an open-source foundation. The stack consists of two main components: XCP-ng and Xen Orchestra. XCP-ng is the equivalent of ESXi and is directly installed on the hardware. With the recent release of 8.3, XOA-Lite is now part of the stack, allowing for a GUI experience on the host without requiring an external controller. Xen Orchestra is a vCenter-like control plane that centralizes control. Unlike vCenter, it is installed on another machine, and hosts can be controlled by multiple XO instances. For day-to-day operations, it runs on an Ubuntu server VM, though I have an instance installed through my main laptop's WSL instance. Overall, t...
Comments
Post a Comment