I am new to Microsoft Windows clustering, and we have an environment in which it is required that we bring 'clustered roles' down and up on schedule. Currently, I have been manually processing this, but would like to automate it using Powershell.
I have read through the Cmdlets here , but can't seem to find one that references roles specifically. I was looking at the commands to stop the entire cluster, but that looks like it will take down resources that are not covered by the two roles that I am specifically required to take down.
Example of role I would like to bring down:
Stop-ClusterResource is your friend. This cmdlet takes one selected part of cluster (one resource) offline. Then you can Start-ClusterResource at the desired time.
Stop/Start/Query Microsoft Windows Cluster Roles with Powershell [Tested in Windows Server 2012-R2]
C:\>powershell Stop-ClusterGroup "ARCSDE52"
Name OwnerNode State
---- --------- -----
ARCSDE52 PRODNODE_AC Offline
C:\>powershell Get-ClusterGroup "ARCSDE52"
Name OwnerNode State
---- --------- -----
ARCSDE52 PRODNODE_AC Offline
C:\>powershell Start-ClusterGroup "ARCSDE52" -Wait 0
Name OwnerNode State
---- --------- -----
ARCSDE52 PRODNODE_AC Pending
C:\>powershell Get-ClusterGroup "ARCSDE52"
Name OwnerNode State
---- --------- -----
ARCSDE52 PRODNODE_AC Online
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!
I have been trying to export a few mailboxes for the past 2 days with only 1 sucessful export.
I'm currently trying to export an archive of a user but it stays "queued" even tho there are no other export requests:
[PS] C:\Windows\system32>Get-MailboxExportRequestStatistics -Identity Cam.Ansell\mailboxexport1
Name Status SourceAlias PercentComplete
---- ------ ----------- ---------------
MailboxExport1 Queued cansell 0
any ideas how to force it to start it?
Try restarting the MS Exchange Mailbox Replication service on the CAS server.
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]$_}
I have an interesting/annoying problem with some VBScripts running on Windows 2003 Server (they run fine on XP).
The scripts basically periodically call WMI objects to extract performance information and write it to a log file. It's started by Scheduled Tasks at 12:05 each morning and runs until midnight (or would if it didn't keep crashing). It's owned by Administrator and the task is "cscript xx.vbs blah blah blah".
Sometimes it runs for hours, sometimes only a few minutes. The calls are of the form:
set objWMI = getObject("winmgmts:\\.\root\cimv2")
: : :
do lots of times:
set itemCpu = wmi.get("Win32_PerfRawData_PerfOS_Processor.Name='_Total'")
The error it comes back with is a dialog box stating that the remote procedure call failed to execute but no extra information (it does give a 32-bit hex number and I'll update this question with it next time it happens but my Google searches turned up very generic pages so I'm not sure the code will help).
It also used to crash out (same error) with the following line but I haven't seen a problem with this one since I changed it to use Win32_Perf Raw Data_PerfOS_Memory.
set colMem = wmi.execQuery("select AvailableKBytes" & _
" from Win32_PerfFormattedData_PerfOS_Memory",,48)
I gather it's not network-related since it's on the same machine.
I've also tried to set objWMI to nothing and do another getObject every time through the loop but that didn't help.
One other possible problem, it's actually running inside VMWare Workstation (but so is the XP) - next week I'll get a physical-PC setup of Win2k3 running to test it there.
The strange thin is, it sometimes runs for hours without problems, collecting the data and sending it to the log file. Other times, it crashes in ten minutes.
Any ideas from the Windows gurus out there among us?
UPDATE:
Okay, it finally failed again. Here's my little effort at screen capture:
+-------------------------------------------------+
| Windows Script Host |X|
+-------------------------------------------------+
| / Script: C:\Program Files\blah\blah.vbs |
| /\ Line: 271 |
| Char: 2 |
| Error: The remote procedure call |
| failed and did not execute. |
| Code: 800706BF |
| Source: SWbemServicesEx |
+-------------------------------------------------+
Line 271 is:
set itemCpu = wmi.get("Win32_PerfRawData_PerfOS_Processor.Name='_Total'")
with wmi having been previously set with:
set wmi = getObject("winmgmts:\\.\root\cimv2")
(this one is continuously being re-created inside the loop, so I don't think it's an issue with the RPC connection going stale).
The error 1722(0x6BF) is : The RPC server is unavailable.
One suggestions : free all objects explicitly in your script
To perform best diagnose try to sniff your network using Microsoft Network Monitor 3.2 and search for issue.(view this help How to capture network traffic with Network Monitor)
Good look.
If your script is checking any user accounts when it runs take a look at this hotfix. It only a problem on 2003 which may explain why it works fine on your XP system.
http://support.microsoft.com/kb/933593
It was causing some random problems for us at work that didn't entirely fit the description in the article but the hotfix did fix our problems.