I'm running homeassistant on a RaspberryPi3 in my local network and what I want to achieve is a switch inside homeassistant to switch on and off my computer (Win10)
Apparently my Desktop PC does not support Wake on LAN from a real "shutdown" to S5, so I'm looking for a solution to remotely hibernate it
What I've done/achieved so far:
- Wake on LAN is working when I manually shutdown with shutdown /h
- remote shutdown is working with net rpc shutdown -I IPADDRESS -U USERNAME%PASSWORD
What I've also tried, but failed:
- running a sshd on Windows (tried with cygwin and openssh port) but failed to start
So the core questions would be either
- If I can manage to put the Windows machine to hibernate instead of shutdown from remote
or
- manage to get WOL working with a completely shutdown machine
Though, Solution 1 would be more convenient to me
Thanks in Advance for any help/hints
I am in the same boat (Home Assistant on a Pi, need to hibernate a Windows computer). I installed this tool from Github on the Windows PC. It's a program that listens for GET requests on a specified port, and will Shutdown, Restart, and Hibernate the host Windows computer.
Now, whenever I send a GET to http://windows.computer.IP.address:PORT/SECRET/ the computer hibernates.
I have been running VMware for the last year no problems, today I opened it up to start one of my VM and get an error message, see screen shot.
I did follow the link and went through the steps, on step 4 I need to mount a volume using "mountvol".
when I try to mount a volume using mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\ it keeps saying The directory is not empty. I even created a partition with 2GB and still the same message.
My Questions:
How can I mount the volume that is not empty even though it is?
Why did this Device/Credential Guard auto enable itself and how can I get rid of it or disable it.
CMD:
There is a much better way to handle this issue. Rather than removing Hyper-V altogether, you just make alternate boot to temporarily disable it when you need to use VMWare. As shown here...
http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx
C:\>bcdedit /copy {current} /d "No Hyper-V"
The entry was successfully copied to {ff-23-113-824e-5c5144ea}.
C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off
The operation completed successfully.
note: The ID generated from the first command is what you use in the second one. Don't just run it verbatim.
When you restart, you'll then just see a menu with two options...
Windows 10
No Hyper-V
So using VMWare is then just a matter of rebooting and choosing the No Hyper-V option.
If you want to remove a boot entry again. You can use the /delete option for bcdedit.
First, get a list of the current boot entries...
C:\>bcdedit /v
This lists all of the entries with their ID's. Copy the relevant ID, and then remove it like so...
C:\>bcdedit /delete {ff-23-113-824e-5c5144ea}
As mentioned in the comments, you need to do this from an elevated command prompt, not powershell. In powershell the command will error.
update:
It is possible to run these commands in powershell, if the curly braces are escaped with backtick (`). Like so...
C:\WINDOWS\system32> bcdedit /copy `{current`} /d "No Hyper-V"
Device/Credential Guard is a Hyper-V based Virtual Machine/Virtual Secure Mode that hosts a secure kernel to make Windows 10 much more secure.
...the VSM instance is segregated from the normal operating
system functions and is protected by attempts to read information in
that mode. The protections are hardware assisted, since the hypervisor
is requesting the hardware treat those memory pages differently. This
is the same way to two virtual machines on the same host cannot
interact with each other; their memory is independent and hardware
regulated to ensure each VM can only access it’s own data.
From here, we now have a protected mode where we can run security
sensitive operations. At the time of writing, we support three
capabilities that can reside here: the Local Security Authority (LSA),
and Code Integrity control functions in the form of Kernel Mode Code
Integrity (KMCI) and the hypervisor code integrity control itself,
which is called Hypervisor Code Integrity (HVCI).
When these capabilities are handled by Trustlets in VSM, the Host OS
simply communicates with them through standard channels and
capabilities inside of the OS. While this Trustlet-specific
communication is allowed, having malicious code or users in the Host
OS attempt to read or manipulate the data in VSM will be significantly
harder than on a system without this configured, providing the
security benefit.
Running LSA in VSM, causes the LSA process itself (LSASS) to remain in
the Host OS, and a special, additional instance of LSA (called LSAIso
– which stands for LSA Isolated) is created. This is to allow all of
the standard calls to LSA to still succeed, offering excellent legacy
and backwards compatibility, even for services or capabilities that
require direct communication with LSA. In this respect, you can think
of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’
instance that simply communicates with the isolated version in
prescribed ways.
And Hyper-V and VMware didn't work the same time until 2020, when VMware used Hyper-V Platform to co-exist with Hyper-V starting with Version 15.5.5.
How does VMware Workstation work before version 15.5.5?
VMware Workstation traditionally has used a Virtual Machine Monitor
(VMM) which operates in privileged mode requiring direct access to the
CPU as well as access to the CPU’s built in virtualization support
(Intel’s VT-x and AMD’s AMD-V). When a Windows host enables
Virtualization Based Security (“VBS“) features, Windows adds a
hypervisor layer based on Hyper-V between the hardware and Windows.
Any attempt to run VMware’s traditional VMM fails because being inside
Hyper-V the VMM no longer has access to the hardware’s virtualization
support.
Introducing User Level Monitor
To fix this Hyper-V/Host VBS compatibility issue, VMware’s platform
team re-architected VMware’s Hypervisor to use Microsoft’s WHP APIs.
This means changing our VMM to run at user level instead of in
privileged mode, as well modifying it to use the WHP APIs to manage
the execution of a guest instead of using the underlying hardware
directly.
What does this mean to you?
VMware Workstation/Player can now run when Hyper-V is enabled. You no
longer have to choose between running VMware Workstation and Windows
features like WSL, Device Guard and Credential Guard. When Hyper-V is
enabled, ULM mode will automatically be used so you can run VMware
Workstation normally. If you don’t use Hyper-V at all, VMware
Workstation is smart enough to detect this and the VMM will be used.
System Requirements
To run Workstation/Player using the Windows Hypervisor APIs, the
minimum required Windows 10 version is Windows 10 20H1 build
19041.264. VMware Workstation/Player minimum version is 15.5.5.
To avoid the error, update your Windows 10 to Version 2004/Build 19041 (Mai 2020 Update) and use at least VMware 15.5.5.
I'm still not convinced that Hyper-V is The Thing for me, even with last year's Docker trials and tribulations and I guess you won't want to switch very frequently, so rather than creating a new boot and confirming the boot default or waiting out the timeout with every boot I switch on demand in the console in admin mode by
bcdedit /set hypervisorlaunchtype off
Another reason for this post -- to save you some headache: You thought you switch Hyper-V on with the "on" argument again? Nope. Too simple for MiRKoS..t. It's auto!
Have fun!
G.
To make it super easy:
Just download this script directly from Microsoft.
Run your Powershell as an admin and then execute following commands:
To Verify if DG/CG is enabled DG_Readiness.ps1 -Ready
To Disable DG/CG. DG_Readiness.ps1 -Disable
For those who might be encountering this issue with recent changes to your computer involving Hyper-V, you'll need to disable it while using VMWare or VirtualBox. They don't work together. Windows Sandbox and WSL 2 need the Hyper-V Hypervisor on, which currently breaks VMWare. Basically, you'll need to run the following commands to enable/disable Hyper-V services on next reboot.
To disable Hyper-V and get VMWare working, in PowerShell as Admin:
bcdedit /set hypervisorlaunchtype off
To re-enable Hyper-V and break VMWare for now, in PowerShell as Admin:
bcdedit /set hypervisorlaunchtype auto
You'll need to reboot after that. I've written a PowerShell script that will toggle this for you and confirm it with dialog boxes. It even self-elevates to Administrator using this technique so that you can just right click and run the script to quickly change your Hyper-V mode. It could easily be modified to reboot for you as well, but I personally didn't want that to happen. Save this as hypervisor.ps1 and make sure you've run Set-ExecutionPolicy RemoteSigned so that you can run PowerShell scripts.
# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);
# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;
# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
# We are running as an administrator, so change the title and background colour to indicate this
$Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
$Host.UI.RawUI.BackgroundColor = "DarkBlue";
Clear-Host;
}
else {
# We are not running as an administrator, so relaunch as administrator
# Create a new process object that starts PowerShell
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";
# Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
$newProcess.Arguments = "-windowstyle hidden & '" + $script:MyInvocation.MyCommand.Path + "'"
# Indicate that the process should be elevated
$newProcess.Verb = "runas";
# Start the new process
[System.Diagnostics.Process]::Start($newProcess);
# Exit from the current, unelevated, process
Exit;
}
Add-Type -AssemblyName System.Windows.Forms
$state = bcdedit /enum | Select-String -Pattern 'hypervisorlaunchtype\s*(\w+)\s*'
if ($state.matches.groups[1].ToString() -eq "Off"){
$UserResponse= [System.Windows.Forms.MessageBox]::Show("Enable Hyper-V?" , "Hypervisor" , 4)
if ($UserResponse -eq "YES" )
{
bcdedit /set hypervisorlaunchtype auto
[System.Windows.Forms.MessageBox]::Show("Enabled Hyper-V. Reboot to apply." , "Hypervisor")
}
else
{
[System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
exit
}
} else {
$UserResponse= [System.Windows.Forms.MessageBox]::Show("Disable Hyper-V?" , "Hypervisor" , 4)
if ($UserResponse -eq "YES" )
{
bcdedit /set hypervisorlaunchtype off
[System.Windows.Forms.MessageBox]::Show("Disabled Hyper-V. Reboot to apply." , "Hypervisor")
}
else
{
[System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
exit
}
}
the simplest solution for this issue is to download the "Device Guard and Credential Guard hardware readiness tool" to correct the incompatibility :
https://www.microsoft.com/en-us/download/details.aspx?id=53337
Decompress the zip
you will find :
execute the "DG_Readiness_Tool_v3.6.ps1" with PowerShell
Now you should be able to power on your virtual machine normally .
I don't know why but version 3.6 of DG_Readiness_Tool didn't work for me.
After I restarted my laptop problem still persisted.
I was looking for solution and finally I came across version 3.7 of the
tool and this time problem went away.
Here you can find latest powershell script:
DG_Readiness_Tool_v3.7
I also struggled a lot with this issue. The answers in this thread were helpful but were not enough to resolve my error. You will need to disable Hyper-V and Device guard like the other answers have suggested. More info on that can be found in here.
I am including the changes needed to be done in addition to the answers provided above. The link that finally helped me was this.
My answer is going to summarize only the difference between the rest of the answers (i.e. Disabling Hyper-V and Device guard) and the following steps :
If you used Group Policy, disable the Group Policy setting that you
used to enable Windows Defender Credential Guard (Computer
Configuration -> Administrative Templates -> System -> Device Guard
-> Turn on Virtualization Based Security).
Delete the following registry settings:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LsaCfgFlags
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\EnableVirtualizationBasedSecurity
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard\RequirePlatformSecurityFeatures
Important :
If you manually remove these registry settings, make sure to delete
them all. If you don't remove them all, the device might go into
BitLocker recovery.
Delete the Windows Defender Credential Guard EFI variables by using
bcdedit. From an elevated command prompt(start in admin mode), type
the following commands:
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d
Restart the PC.
Accept the prompt to disable Windows Defender Credential Guard.
Alternatively, you can disable the virtualization-based security
features to turn off Windows Defender Credential Guard.
install the latest vmware workstation > 15.5.5 version
which has support of Hyper-V Host
With the release of VMware Workstation/Player 15.5. 5 or >, we are
very excited and proud to announce support for Windows hosts with
Hyper-V mode enabled! As you may know, this is a joint project from
both Microsoft and VMware
https://blogs.vmware.com/workstation/2020/05/vmware-workstation-now-supports-hyper-v-mode.html
i installed the VMware.Workstation.Pro.16.1.0
and now it fixed my issue now i am using docker & vmware same time even my window Hyper-V mode is enabled
Windows 1909 (18363.1377)
In my case I was using windows 1909, Device Guard was disabled and so was the Hyper V. While trying docker I installed and enabled wsl2. After uninstalling wsl from control panel and disabling it from powershell my vmware started working again.
Following is the command to disable wsl
Run in powershell as admin
dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux
Uninstall WSL shown in the screenshot
Reboot your system
If you are someone who maintains an open customized "Run as administrator" command prompt or powershell command line window at all the times you can optionally setup the following aliases / macros to simplify executing the commands mentioned by #gue22 for simply disabling hyper-v hypervisor when needing to use vmware player or workstation and then enabling it again when done.
doskey hpvEnb = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype auto ^& echo.^&echo now reboot to enable hyper-v hypervisor )
doskey hpvDis = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype off ^& echo.^&echo now reboot to disable hyper-v hypervisor )
doskey bcdL = bcdedit /enum ^& echo.^&echo now see boot configuration data store {current} boot loader settings
With the above in place you just type "hpvenb" [ hypervisor enabled at boot ], "hpvdis" [ hypervisor disabled at boot ] and "bcdl" [ boot configuration devices list ] commands to execute the on, off, list commands.
Well Boys and Girls after reading through the release notes for build 17093 in the wee small hours of the night, I have found the change point that affects my VMware Workstation VM's causing them not to work, it is the Core Isolation settings under Device Security under windows security (new name for windows defender page) in settings.
By default it is turned on, however when I turned it off and restarted my pc all my VMware VM's resumed working correctly. Perhaps a by device option could be incorporated in the next build to allow us to test individual devices / Apps responses to allow the core isolation to be on or off per device or App as required .
Here are proper instructions so that everyone can follow.
First download Device Guard and Credential Guard hardware readiness tool from this link: https://www.microsoft.com/en-us/download/details.aspx?id=53337
extract the zip folder content to some location like: C:\guard_tool
you will have files like this copy file name of ps1 extension file in my case its v3.6 so it will be : DG_Readiness_Tool_v3.6.ps1
Next click on start menu and search for powershell and then right click on it and run as Administrator.
After that you will see blue color terminal enter command cd C:\guard_tool , replace the path after cd with your extracted location of the tool
Now enter command: .\DG_Readiness_Tool_v3.6.ps1 -Disable
After that reboot system
When your system is restarting it boot time system will show notification with black background to verify that you want to disable these features so press F3 to confirm.
do +1 if it helped :)
QUICK SOLUTION EVERY STEP:
Fixed error in VMware Workstation on Windows 10 host
Transport (VMDB) error -14: Pipe connection has been broken.
Today we will be fixing VMWare error on a windows 10 computer.
In RUN box type "gpedit" then Goto [ERROR SEE POINT 3]
1- Computer Configuration
2- Administrative Templates
3- System - Device Guard : IF NO DEVICE GUARD : (DOWNLOAD https://www.microsoft.com/en-us/download/100591 install this "c:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)\PolicyDefinitions" COPY to c:\windows\PolicyDefinitions )
4- Turn on Virtualization Based Security.
Now Double click that and "Disable"
Open Command Prompt as Administrator and type the following
gpupdate /force [DONT DO IF YOU DONT HAVE DEVICE GUARD ELSE IT WILL GO AGAIN]
Open Registry Editor, now Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Add a new DWORD value named EnableVirtualizationBasedSecurity and set it to 0 to disable it.
Next Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Add a new DWORD value named LsaCfgFlags and set it to 0 to disable it.
In RUN box, type Turn Windows features on or off, now uncheck Hyper-V and restart system.
Open command prompt as a administrator and type the following commands
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
bcdedit /set hypervisorlaunchtype off
Now, Restart your system
I had the same problem. I had VMware Workstation 15.5.4 and Windows 10 version 1909 and installed Docker Desktop.
Here how I solved it:
Install new VMware Workstation 16.1.0
Update my Windows 10 from 1909 to 20H2
As VMware Guide said in this link
If your Host has Windows 10 20H1 build 19041.264 or newer,
upgrade/update to Workstation 15.5.6 or above.
If your Host has Windows 10 1909 or earlier, disable Hyper-V on the host to resolve this issue.
Now VMware and Hyper-V can be at the same time and have both Docker and VMware at my Windows.
We have a web service that is running slowly in production. In QA and UAT it is fine but those are housed at our corporate HQs. But production is in a data center in the cloud. I ran wireshark and found that it is making at least 6 calls to NBNS WPAD (each one timing out), each taking about 3/4 of a second making it very slow. I want to turn off WPAD since the environment is not configured to use it but it is still making the calls and just wasting time.
My platform is windows server 2008 r2 with IE9. I want to completely disable WPAD DNS queries (and NBNS queries). We don't use a proxy. We don't use DHCP. I want to stop WPAD but I haven't been successful. I have tried the following:
1.disable "automatically detect settings" in IE
2.disable "use automatic configuration script" in IE
3.Checked that WinHTTP Web Proxy Auto-Discovery Service is not running automatically, it is set to run manual so I think that should be ok.
4.Executed "Netsh winhttp show proxy" which tells me Direct access (no proxy server).
What am I missing that needs to be turned off?
Many suggestions around disabling WPAD focus on Internet Explorer user settings. While this will tell IE to not use auto proxy detection, it will not stop the WinHTTP Web Proxy Auto-Discovery Service from querying for wpad. Some have suggested disabling this service entirely, but as of Windows 10, it is required for the IP Helper service and not recommended to disable it.
In the MS16-063 notes, you can see their suggested workaround for the (fixed) vulnerability is to edit the hosts file (c:\windows\system32\drivers\etc\hosts).
255.255.255.255 wpad.
Although the patch fixed that specific vulnerability, the workaround is still an option for disabling WPAD. In my testing, it does stop the queries. As the article notes:
Impact of workaround. Autoproxy discovery will not work, and for this reason, some applications, such as Internet Explorer, will not be able to load websites properly.
Keep in mind that WPAD can be a good thing when setup properly. As with any advice from the Internet, be sure to do your own testing before applying any changes. For example, if you make this change to corporate laptops and they travel to a site that requires WPAD, they will not work.
Source: Microsoft forums.
Note that you can easily use Wireshark to see if a computer is doing wpad queries by using the filter: dns.qry.name contains "wpad"
Group Policy Editor
Edit "Default Domain Policy"
User Configuration
Policies
Windows Settings
Connection/Automatic Browser Configuration
Automatically detect configuration settings -> DISABLE
I have tested removing proxy from computers by renaming the WPAD key and rebooting.
You can also use IEAK11 to create a GPO to remove "Automatically detect settings" and that is why the script uses gpupdate to apply the GPO as well.
If you already applied the change to a computer this script won't do changes and will exit. The basic script is bellow.
Even when you turn on in Internet Explorer "Automatically detect settings" proxy is not used and WPAD key is recreated but with no proxy. This setting is no longer recommended as makes your computer vulnerable (https://it.slashdot.org/story/16/08/13/0149241/disable-wpad-now-or-have-your-accounts-compromised-researchers-warn) .
REM Script to delete the cached proxy configuration, clear IE cache, flushdns, rename WPAD key and delete the original; reboot is required
gpupdate
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad.bad" >nul
if %ERRORLEVEL%==0 goto END
ELSE
(
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections" /v "DefaultConnectionSettings" /f
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections" /v "SavedLegacySettings" /f
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
ipconfig /flushdns
reg copy "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad" "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad.bad"
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad" /f
echo n | gpupdate /force /wait:0
shutdown.exe /r /t 30 )
:END
for my pihole (Raspberry PI based ad blocking software DNS level) i added the below in the hosts file
pi#raspberrypi:~ $ cat /etc/hosts
127.0.0.1 localhost
0.0.0.0 wpad wpad.my.home
:: wpad wpad.my.home
and my nslookup shows
pi#raspberrypi:~ $ nslookup wpad.my.home
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: wpad.my.home
Address: 0.0.0.0
pi#raspberrypi:~ $ nslookup wpad
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: wpad
Address: 0.0.0.0
if you are on a Windows machine you can open "C:\Windows\System32\drivers\etc\hosts" and add these entries
0.0.0.0 wpad
0.0.0.0 wpad.my.home
change my.home to whatever local domain you have
I have a windows 2003 box setup with virtual box and I can't powershell to work with it.
I try this on my windows 7 machine
Get-Service –ComputerName myserver
I get back
Get-Service : Cannot open Service Control Manager on computer 'myserver'. This operation might require other privileges.
At Script1.ps1:2 char:4
+ gsv <<<< -cn myserver
+ CategoryInfo : NotSpecified: (:) [Get-Service], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetServiceCommand
While searching around I found I should try and use Enable-PSRemoting.
I did this and now when I try to use it I get
WinRM already is set up to receive requests on this machine. WinRM
already is set up for remote management on this machine.
Yet I still get the same error. Is this because I am using a virtual machine? I setup the virtual OS to be on my domain and I can even use my AD account credentials to log in.
I can get other information back from it.
So it is not like I can't connect to it with powershell.
With PowerShell V2 you've got two approachs for remote commands.
Commands with built-in remoting :
A small set of commands in PowerShell v2 have a -ComputerName parameter, which allows you to specify the target machine to access.
Get-Process
Get-Service
Set-Service
Clear-EventLog
Get-Counter
Get-EventLog
Show-EventLog
Limit-EventLog
New-EventLog
Remove-EventLog
Write-EventLog
Restart-Computer
Stop-Computer
Get-HotFix
These commands do their own remoting either because the underlying infrastructure already supports remoting or they address scenarios that are of particular importance to system management. They are built on the top of DCOM and, on the access point of view, you can use them when you can establish a session with the remote machine with commands like NET.exe or PSExec.exe.
You are trying to use one of them and you've got a problem with credentials (-cred parameter), because your token credentials can't be used to establish an admin session to the remote machine.
The PowerShell remoting subsystem :
Before you can use PowerShell remoting to access a remote computer, the remoting service on that computer has to be explicitly enabled. You do so using the Enable-PSRemoting cmdlet. If you are working in workgroup you also need to enable the server to enter on your client computer with this command (on your client computer as administrator):
Set-Item WSMan:\localhost\Client\TrustedHosts *
Then, you will use New-PSSession Cmdlet (with -computername and -credentials) to create a session object. Then Invoke-Command (with -session and -scriptblock) cmdlet allows you to remotely invoke a scriptblock on another computer. This is the base element for most of the features in remoting. You can also use Enter-PSSession to establish an interactive (SSL like) PowerShell command line with the server.
Useful link : Layman’s guide to PowerShell 2.0 remoting
Test this :
$sess = New-PSSession -ComputerName myServer-Credential (Get-Credential)
Invoke-Command -Session $sess -ScriptBlock {get-service}
...
Remove-PSSession -Session $sess
If it is still important, here is my workaround:
I got an unprivileged user called 'usser' who wants powershell(v2) remoting from client A to server B.
Steps:
enable-psremoting on Targetserver B as admin
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI on Targetserver B as admin
Add "usser" with full privileges
Now comes the exciting part:
sc sdshow scmanager on Targetserver B as admin
Copy the SDDL output
sc sdset scmanager (f.e.:)"D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)" , in the Output you have to fill after this part (A;;CCLCRPWPRC;;;SY) this = (A;;KA;;;SID)
SID stands of course for the SID of the unprivileged "usser"-user
when everything should be fine, it will similiar looks like this :
D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
Hope you will enjoy that little but complicated workaround.
Viewing and manipulating services requires administrative privileges on the target machine.
I was able to duplicate your error message by attempting to run Get-Service -ComputerName MyServer while logged in as a user account that doesn't have administrative rights to the server in question.
You can resolve this by either granting the workstation user account administrative privileges on the target server or by creating a a local group on the server and granting invocation privileges to members of that group. If you want to do the latter, see the following article.
msgoodies: Using a PS Session without having Administrative Permissions
Building on #scusi marcus's brilliant answer here:
Let's say I have an unprivileged/limited user called 'user1' who wants powershell(v2+) remoting from client machine A to targetserver B.
Steps:
From elevated powershell prompt on targetserver B, run enable-psremoting. Accept several Y/N dialog confirmations or else run with -force switch.
In same elevated prompt as step 1, Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI
In the resulting dialog, add "user1". Read privileges should be sufficient unless you are planning on remotely manipulating services, in which case you will want Full Control.
On targetserver B, from an elevated (non-powershell) prompt or as an administrator, run sc sdshow scmanager. Copy the SDDL output. May look something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
UPDATE: If we add the limited user to the target computer's Remote Management Users group, we can add (A;;LCRPWPDTLO;;;RM) to the D: portion of the above SDDL string, and skip steps 5 and 6 below.
Determine the SID of the underprivileged user account (in our case, "user1"). (Hint: try wmic useraccount where name='user1' get sid)
Insert the following text into the output we copied in step 5: (A;;KA;;;*SID*) where *SID* is the SID of the user determined in step 5. Insert it somewhere in a place before the S: part of the SDDL string retrieved in step 4. So now you should have a string looking something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
On targetserver B, run sc sdset scmanager followed by our new modified SDDL string. So the entire command would look something like this:
sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
You should now be able to remotely access the Service Control Manager on the remote server while logged into client machine A as "user1".
On client machine A, you may find that when you run Get-Service –ComputerName remoteserver not all services are listed. You may need to repeat the above process (starting at step 4) for a specific service that you need remote access to, but which is not listed in your Get-Service output on client machine A. For instance, if the sqlserveragent service is not listed (but you know it is present on the targetserver), you would again log in to targetserver B and execute sc sdshow but this time not for scmanager but for the sqlserveragent service, so sc sdshow sqlserveragent. You would again receive some SDDL output that would need to be manipulated as above. At this point, it may be worth learning more about SDDL (Google it - this link was helpful for me), with the main caveat to watch for the D: and S: portions of the SDDL string and make sure you aren't messing with the S: part.
I know that this isn't the ideal answer to this question, but I was having a similar issue trying to use PowerShell to talk to a Windows 7 box. Turns out, WMI hadn't been installed with the native PSv2 that comes with Win7.
As soon as I installed v3 as part of the WMI 3.0 package, the problem solved itself. I'd suggest making sure that all the relevant WMI services are running on your server. Unless you have conflicts, I'd also recommend upgrading to WMI 3.0.
Does anyone had a successful experience with VirtualKD setup on Linux host running VMWare Workstation 8 (with Win7 guests)?
Despite the facts there's a lot of admiring comments about 'speed' and 'other benefits' of that VirtualKD, most of them come from Windows/VirtualBox users, and I really don't want to waste my time on trying to get it working on unsupported configuration.
P.S. Official VirtualKD forum has a similar thread that is still unanswered for two years, so decided to ask for reviews here.
P.P.S. My actual problem is that VMWare's socket-based COM port debugging is very slow.. it takes 10 to 20x more time to copy debug output from debuggee to debugger machine, than it takes to print same output to DbgView.
Does anyone had a successful experience with VirtualKD setup on Linux host running VMWare Workstation 8 (with Win7 guests)?
VirtualKD is a Windows-only application. The poster on the forum has worked around the problem of it being Windows-only by redirecting a Unix socket to TCP, therefore allowing Windows clients to connect over the network.
I've used socat to successfully bridge two VMs using a tcp socket. I created pipes in /tmp and ran socat between them; one VM can then debug the other.
In my case, because I'd configured the debugger to use serial connections I was rate limited by the serial connections. I haven't tried the VirtualKD-style setup; however, my bet is it won't work. From the VirtualKD explanation of its internals on VMWare, the client-side code is basically using hypervisor provided functionality. VirtualBox has to be patched by VirtualKD; I expect this is to provide such functionality to VirtualBox clients.
The bad news is this means, ultimately, that the Linux host hypervisor (VMware/VirtualBox on the host) must know to process that information and pass it out to the appropriate location. By default, it won't know how to do this.
I have a successful experience running it on Windows if anyone is looking for that:
Install VirtualBox 5.x or less and create a virtual machine with a Windows .iso SATA device and set it up
Download VirtualKD-3.0
Open the VM and run vminstall.exe on the guest
On admin cmd on the guest: bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200
Shut down VM, close VirtualBox and kill the VBoxSVC.exe process
Run VirtualIntegration.exe. If it crashes open an admin cmd and cd to C:\Program Files\Oracle\VirtualBox and then type vboxmanage setextradata <VMNAME> VBoxInternal/Devices/VirtualKD/0/Config/Path <VirtualKD-3.0 folder> i.e. vboxmanage setextradata Windows7 VBoxInternal/Devices/VirtualKD/0/Config/Path C:\Users\lewis\Downloads\VirtualKD-3.0
Open vmmon64.exe and set the debugger path i.e C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe, and then select WINDBG.EXE and start debugger automatically
Launch VM and highlight the VirtualKD entry and press f8 and disable driver signature enforcement and you will soon break into the debugger at nt!RtlpBreakWithStatusInstruction, which is a debugger symbol for the first address of the DbgBreakPointWithStatus, which is called from InitBootProcessor, which is the breakpoint you'd get from sxe ibp;.reboot. There is an earlier breakpoint of sxe ld:nt
You will need to unpatch the VM in order to be able to boot it without vmmon open. VirtualKD is good for logging with debugging protocol packets and automating windbg connection but you can't boot debug with it. In order for boot debugging to work you will need to create a COM1 serial port on the VM and set it to create a pipe \\.\pipe\pipename. You then need to connect to the pipe via windbg manually. Make sure that you have done bcdedit /bootdebug /on && bcdedit /bootdebug {bootmgr} /on && bcdedit /set {bootmgr} debugtype serial && bcdedit /set {bootmgr} baudrate 115200 && bcdedit /set {bootmgr} debugport 1 on the guest before booting.