One of our customer got hundreds of applications which we believe needs to be retired, so we would like to have an automated solution created which will allow us to confirm they can be retired. The script\query\tool will need to check deployments, dependencies, task sequences, devices that still require this version etc.
Has anyone run into the same requirement, please help ?
This can be achieved by using the Config Manager PowerShell Module. The 'IsExpired' property of the CMApplication object indicates whether the application has been retired.
Get-CMApplication -Name $AppName | Select-Object -ExpandProperty IsExpired
Once you understand the object and property, you could run a query where only applications are selected where the 'IsExpired' status is $true.
Get-CMApplication | Where-Object {$_.IsExpired -eq "$True"}
I'd recommend running this on a subset of applications first if you have a large repository.
Related
I have a working PS script that gets the boot time of remote servers
#$ServerArray is the list of servers
$cso = New-CimSessionOption -Protocol Dcom
$cs = New-CimSession -ComputerName $ServerArray -SessionOption $cso
Get-CimInstance -CimSession $cs -ClassName win32_operatingsystem -OperationTimeoutSec 10 | select csname, Caption, lastbootuptime | sort lastbootuptime | format-table -autosize
Result:
csname Caption lastbootuptime
------ ------- --------------
server1 Microsoft Windows Server 2012 R2 Standard 10/30/2021 3:07:23 AM
server2 Microsoft Windows Server 2012 R2 Standard 10/30/2021 3:12:35 AM
server3 Microsoft Windows Server 2012 R2 Standard 10/30/2021 3:13:34 AM
Are there any other details that can be extracted using PowerShell or another API to show that the server has properly booted?
Note: This may be difficult to use PowerShell for depending on the mechanism of execution; PowerShell Remoting is not available during early stages of boot, nor is an interactive CLI. However, some agents or services (like VMware Tools as an example) can facilitate remote execution at times like these. Scheduled Tasks can also be leveraged to run code locally during some earlier boot phases. Though this answer centers around PowerShell, the general information can be used with other programming languages as well.
There are boot states of Windows you can attempt to look for ways to check these but the most reliable way I've found to know if the computer is in a state for a user to log on is to wait for Get-Process winlogon to return a process back. Once winlogon is running, the computer is near or able to facilitate logon sessions, pending completion of GPO application.
This SuperUser answer explains how to use the Windows Performance Toolkit (part of the Windows SDK) to initiate a boot trace and disseminate its report, but that isn't the focus of this question or answer. I'm including it here to show that waiting for winlogon is the right way to identify when the system is ready for interaction; execution of winlogon is actually the final Windows boot phase and that answer exemplifies this.
Note: Technically, logging in and waiting for scheduled tasks to complete on login is the final step but that portion comes after after kernel boot has completed, and can be repeated for multiple logon sessions. I don't consider this part of the "boot sequence" or system initialization.
As for the boot phases of Windows I've only been able to generate a report of a boot trace using xbootmgr. I'm not sure there is a documented API (win32 or otherwise) exposed to the userspace to check for the current boot phase outside of the boot trace. At this time I can only recommend looking at environmental details to know the current boot phase (such as checking for the winlogon process), although I'm not familiar enough with the environments of the other boot phases to make additional recommendations here.
If I learn more information about the other phases I will update this answer.
GOAL: Rename all AD Objects to new convention and move them to new OU's in a restructured AD hierarchy.
I have a PS script that utilizes the SCCM site module and the Active Directory module to do the following:
Get-CMCollectionMember
For each Member name, Remove-CMDevice
Move-ADObject of the same Member name
Rename-Computer of the same Member name
Reboot the computer
Run SCCM TriggerSchedules for DDR and Hardware Inventory
When I run the triggerschedules, the PSComputerName shows as the computer objects OLD name. Not the new one.
Everything else seems to work - the AD object is moved, then renamed. The 'new' SCCM Device Object shows up in SCCM (via Delta System Discovery - Interval 5 min).
The problem is that SCCM (the client, I suspect) is holding on to old object info.
My question is, short of just reinstalling the client...why is this happening? I am not renaming the object in SCCM - the first step is actually removing the devices from SCCM. They are then rediscovered via Delta system discovery.
When I run...
Invoke-WMIMethod -ComputerName WD001-WK100 -Namespace root\ccm -Class SMS_CLIENT -Name TriggerSchedule $schedule
...at the end of the process, PSComputername is the old name.
Any advice appreciated.
Reinstalling the SCCM Client is simple, and works. I am just running this on the end instead of running cycles, since they all run when the client is reinstalled, anyway. It also clears up my issue:
Install-CMClient -DeviceName $pc -AlwaysInstallClient $true -ForceReinstall $true
Thank you!
How do I extract all Group Policy Objects through PowerShell so I can compare them to the CIS Benchmark configuration guidelines for a safe and secure environment?
No code provided as I am an intern and looking to learn.
EDIT:
Export all GPO via the below.
Get-GPO -All | Foreach-Object {$_.GenerateReport('html') | Out-File "$($_.DisplayName).htm"}
To ensure your GPO is CIS compliant you can't really just run a PowerShell script and let it update them all. Your best bet is to use one of the supplied Microsoft administrative GPO templates.
If you have already set up your environment then you can download the template above and compare it to your current GPOs using the Microsoft Policy Analyzer to ensure you are meeting the security baseline standards set out by CIS Benchmark and the Australian Information Security manual.
I am looking for a tool to know if a given computer on the local network is being remotely accessed by a user or not and ideally I'd like to know who that user is. In my company, we share virtual machines and we keep have to ask members in the team if they use any remote computer. I'd like to have some kind of dashboard that can tell me what computer is being used, and what computer is free.
I am happy to use any kind of commercial solution that would require the install of services on each of the machines that need to be monitored or things like that.
The below is made easier if you're querying from a Windows client joined to the same domain as the system you are querying, and may require certain rights above and beyond a standard domain user. If you run into authentication/permission issues, that would be the first thing I'd check.
There is a tool available at least as far back as Windows XP called "qwinsta". Later versions of Windows have both qwinsta and "query session".
qwinsta /server:computer01
SESSIONNAME USERNAME ID STATE TYPE DEVICE
console 0 Conn wdcon
rdp-tcp 65536 Listen rdpwd
administrator 2 Disc rdpwd
That shows user "administrator" logged in but disconnected. Since in this example computer01 is a Windows Server 2003 system with the default "administration" RDP license, there's a second session listening for someone to connect.
Running the same command again after connecting to that previously disconnected session looks like this:
SESSIONNAME USERNAME ID STATE TYPE DEVICE
[unchanged output removed]
rdp-tcp#25 administrator 2 Active rdpwd
This is enough to answer "is someone currently active via RDP", and if you're using individual usernames, it should answer the "who" as well. If you're all using "testuser" or "administrator" or something, you'll probably want to know the answer to "from what client", and that is not given above.
The above gives a quick basic answer without needing additional tools. For more detailed information, you might look at the cassia library or PSTerminalServices (built on cassia). See some of the answers in this question for more detail.
My first thought on this was to use Sysinternals tools such as PsLoggedOn or LogonSessions. I then found reference to the previously-unknown-to-me qwinsta and rwinsta tools in this blog post from 2003.
You can use a PSModule named PSRdSessions, this module provide some simple funtions
sample of use
Get-RdSession -ComputerName Server01.domain.xyz # return [Cassia.Impl.TerminalServicesSession]
for return [hashtable]
Get-RdSession -ComputerName Server01.domain.xyz | Convert-RdSession # return
for return [pscustomobject]
Get-RdSession -ComputerName Server01.domain.xyz | Convert-RdSession | %{[pscustomobject]$_}
We have various servers that have many directories shared. It's easy enough to look at the share browser to see what the "top level" shares are, but underneath is a jumbled mess of custom permissions, none of which is documented.
I'd like to enumerate all the shares on the domain (definitely all the 'servers', local PCs would be nice) and then recurse down each one and report any deviation from the parent. If the child has the same permissions, no need to report that back.
I'd prefer a simple script-y solution to writing a big C# app, but any method that works will do (even existing software).
For example, I'd like to get:
SERVER1\
\-- C: (EVERYONE: Total control, ADMINs, etc. etc.)
\-- (skip anything that is not the same as above)
\-- SuperSecretStuff (Everyone: NO access; Bob: Read access)
SERVER2\
\-- Stuff (some people)
etc.
I know it isnt scripting, but have you tried ShareEnum? http://technet.microsoft.com/en-us/sysinternals/bb897442.aspx and then export it out? You can also compare to older runs. I don't think there is a cmd line interface (which sucks), but it will get you the info you need
This Powershell script accomplishes your goal.
As it is stated:
This little script will enumerate all the shares on a computer, and list the share-level permissions for each share. It uses WMI to retrieve the shares, and to list the permissions.
Note that this script lists share-level permissions, and not NTFS permissions.
It accepts a number of computers as its input, a single IP, or running it in the local system:
.EXAMPLE
C:\PS> .\Get-SharePermissions # Operates against local computer.
.EXAMPLE
C:\PS> 'computerName' | .\Get-SharePermissions
.EXAMPLE
C:\PS> Get-Content 'computerlist.txt' | .\Get-SharePermissions | Out-File 'SharePermissions.txt'