Unable to run win-install.cmd, Error – permission denied

This post was originally published on this site



I am using HP machine with windows 10, i have installed vmware workstation 11 and using linux and windows server as a VM in it.


To install MAC OS X lion in vmware workstation 11, i am trying to run win-install.cmd but getting an error- permission denied. Please see the below picture:-


Please let me know what i am doing wrong and help me to install MAC OS X lion.




Using the OpenSSH Beta in Windows 10 Fall Creators Update and Windows Server 1709

This post was originally published on this site

I’m thrilled to share that a Beta OpenSSH client and server daemon are available as a Feature-on-Demand in Windows 10 Fall Creators Update and Windows Server 1709. Since our last update blog, we’ve been working hard on a Win32 port of OpenSSH and working closely with members of the OpenSSH Portable and OpenBSD projects with the eventual goal of bringing Win32 support upstream into OpenSSH Portable.

Until then, you should expect OpenSSH support in Windows to continue to improve in future updates of Windows, including upcoming Windows Insider builds. You can track our progress on GitHub where you can find our wiki and the latest builds that include tons of fixes and support for operating systems downlevel to Windows 7 and Server 2008 R2.


OpenSSH is a collection of client/server utilities that enable secure remote login, remote file transfer, and public/private key pair management. It’s an extremely powerful tool that originated as part of the OpenBSD project, and has been used for many years across the BSD, Linux, macOS, and Unix ecosystems.

Note: The OpenSSH client and server are still very much in Beta, so we do not recommend using them in production environments.


Great! So how do I install the bits?

Installing with the Settings UI

To install it using the Settings UI, go to Apps -> Apps and Features -> Manage optional features -> Add a feature:

Apps and featuresManage optional features

Then select OpenSSH Client (Beta) or OpenSSH Server (Beta) and Install:

Add a feature

Installing with PowerShell

To install OpenSSH using PowerShell, first launch PowerShell as an Administrator.

To make sure that the OpenSSH features are available for install:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'

This should return the following output:

Name  : OpenSSH.Client~~~~
State : NotPresent

Name  : OpenSSH.Server~~~~
State : NotPresent

Then, install the server and/or client features:

# Install the OpenSSH Client
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~

# Install the OpenSSH Server
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~

Both of these should return the following output:

Path          :
Online        : True
RestartNeeded : False

Installing with DISM.exe

To install OpenSSH with DISM.exe, first open CMD as an Administrator.

To make sure that OpenSSH features are available for install:

dism /Online /Get-Capabilities | findstr OpenSSH

This should return the following output:

Capability Identity : OpenSSH.Client~~~~
Capability Identity : OpenSSH.Server~~~~

Then, install the server and/or client features:

dism /Online /Add-Capability /CapabilityName:OpenSSH.Client~~~~
dism /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~


Great! You’ve installed OpenSSH. What now?

Configuring the SSH Client (ssh.exe)

Password-based authentication

If you want to use the SSH client with password authentication, no configuration is necessary. Just pop open PowerShell or cmd, and use ssh to connect to your SSH server:

ssh user1@contoso.com

# You can also use domain accounts to login

# UPN syntax works...
ssh user1@domain1@contoso.com
# ...as does NetBIOS syntax
ssh user1domain1@contoso.com

Key-based authentication

If you want to use key-based authentication, you first need to generate some public/private key pairs for your client. From PowerShell or cmd, use ssh-keygen to generate some key files.

cd ~.ssh

This should output something like:

Generating public/private ed25519 key pair.
Enter file in which to save the key (C:Usersuser1.sshid_ed25519):

You can hit Enter to accept the default or specify a path where you’d like your keys to be generated. At this point, you’ll be prompted to use a passphrase to encrypt your private key files.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in C:Usersuser1.sshid_ed25519.
Your public key has been saved in C:Usersuser1.sshid_ed25519.pub.
The key fingerprint is:
SHA256:OIzc1yE7joL2Bzy8/gS0j8eGK7bYaH1FmF3sDuMeSj8 user1@CONTOSO@LOCAL-HOSTNAME
The key's randomart image is:
+--[ED25519 256]--+
|        .        |
|         o       |
|    . + + .      |
|   o B * = .     |
|   o= B S .      |
|   .=B O o       |
|  + =+% o        |
| *oo.O.E         |
|+.o+=o. .        |

Now you have a public/private ED25519 key pair
(the .pub files are public keys and the rest are private keys):

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        11/8/2017  11:09 AM           1679 id_ed25519
-a----        11/8/2017  11:09 AM            414 id_ed25519.pub

Your private key files are the equivalent of a password. You should protect them under any and all circumstances. If someone acquires your private key, they can log in to any SSH server as an identity that authorizes the corresponding public key to log in.

For that reason, we should take advantage of ssh-agent to securely store the private keys within a Windows security context. To do that, we simply start the ssh-agent service (as Administrator) and use ssh-add to store our private key. Then, whenever a private key is needed for authentication, ssh-agent will automatically retrieve your local user’s private key and pass it to your SSH client.

# Make sure you're running as an Administrator
Start-Service ssh-agent

# This should return a status of Running
Get-Service ssh-agent

# Now load your key files into ssh-agent
ssh-add ~.sshid_ed25519

# Now that it's loaded into ssh-agent,
# we don't have to keep the key file anymore
Remove-Item ~.sshid_ed25519

Move the contents of your public key (~.sshid_ed25519.pub) into a text file called authorized_keys in ~.ssh on your server/host.

Note: these directions assume your sshd server is a Windows-based machine using our OpenSSH-based server, and that you’ve properly configured it based on the instructions below (including the installation of the OpenSSHUtils PowerShell module). If you’re using a non-Windows machine, you should replace all remote instances of C:usersuser1 with something like /home/user1. Additionally, the ACL line should be unnecessary that uses PowerShell should be unnecessary.

# Make sure that the .ssh directory exists in your server's home folder
ssh user1@domain1@contoso.com mkdir C:usersuser1.ssh

# Copy your public key file to authorized_keys on your server
scp C:Usersuser1.sshid_ed25519.pub user1@domain1@contoso.com:C:Usersuser1.sshauthorized_keys

# Appropriately ACL the authorized_keys file on your server
ssh --% user1@domain1@contoso.com powershell -c $ConfirmPreference = 'None'; Repair-AuthorizedKeyPermission C:Usersuser1.sshauthorized_keys

Congrats! You should no longer need a password when authenticating as User1 against contoso.com.

Configuring the OpenSSH Server (sshd)

First, it’s worth noting again that this OpenSSH for Windows is still very much in beta form. It should only be used in safe, testing environments.

To enable authentication into an SSH server on Windows, you first have to generate host keys. As an Administrator:

Start-Service ssh-agent

cd C:WindowsSystem32OpenSSH
.ssh-keygen -A
# C:WindowsSystem32OpenSSHssh-keygen.exe: generating new host keys: ED25519
.ssh-add ssh_host_ed25519_key
# Identity added: .ssh_host_ed25519_key (User1@CONTOSO@LOCAL-HOSTNAME)

Due to certain security requirements, you will also have to install our OpenSSHUtils helper module to appropriately ACL your host keys. As an Administrator:

Install-Module -Force OpenSSHUtils

Repair-SshdHostKeyPermission -FilePath C:WindowsSystem32OpenSSHssh_host_ed25519_key

# Use A or Y as your response to the prompts to set file owners

Then you can start sshd and your server is ready to go:

Start-Service sshd

# This should return a Status of Running
Get-Service sshd

Note: currently only the built-in ED25519 authentication key type is supported. In the future, we plan to add support for LibreSSL which will enable additional authentication key types. In the meantime, you can experiment with LibreSSL builds on GitHub.

You may also need to add a firewall rule like this one that allows traffic on port 22 (though your requirements may vary based on your environment, e.g. Domain might be Private):

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Service sshd -Enabled True -Direction Inbound -Protocol TCP -Action Allow -Profile Domain

Stay tuned!

Enjoy playing with OpenSSH on Windows, and keep your eyes peeled on the PowerShell blog for upcoming news.

Prerelease Versioning Added to PowerShellGet and PowerShell Gallery

This post was originally published on this site
With the release of PowerShellGet 1.6.0, PowerShellGet cmdlets and the PowerShell Gallery have added support for prerelease strings for prerelease versions of modules and scripts. You can now publish items to the PowerShell Gallery with a version like 1.0.0-alpha, and you can download items identified as a prerelease. Items can be filtered using prerelease version strings, in both the Gallery UI and via Find-* cmdlets.
Before this feature, if publishers wished to publish a prerelease version of an item, they had to use a version lower than 1.0.0 (ex. 0.0.1). This meant it was not possible to publish a prerelease version of a 2.0.0 item. The other workaround was to change the name of the item to contain the word “prerelease” (ex. MyAwesomeModule-Prerelease), but that required code changes for users when the production version was ready, because it changed the name of the item. 
Now, users can mark their items as prerelease, following the SemVer v1.0.0 guidelines, without affecting the item name or constraints on the version.
Publishers simply add the prerelease string (ie. the part that comes after “2.0.0”) in the metadata, and the version will be considered prerelease. For example:
   ModuleVersion = '2.0.0'
      PrivateData = @{
         PSData = @{
            Prerelease = '-alpha'
To acquire or interact with prerelease items using the PowerShellGet cmdlets, users must add the -AllowPrerelease flag. For example, to find prerelease versions of a module:
   PS:> Find-Module PSReadline -AllowPrerelease -Allversions
To install a prerelease version from the gallery:
   PS:> Install-Module PSReadline -RequiredVersion 2.0.0-beta1 -AllowPrerelease
   PS:> # Note that you may need to add -SkipPublisherCheck for this update to proceed.

To update a module to a prerelease version from the gallery:

   PS:> Update-Module PSReadline -RequiredVersion 2.0.0-beta1 -AllowPrerelease
   PS:> # Updates to 2.0.0-beta1. You may need to add -SkipPublisherCheck.
The PowerShell Gallery UI has also been updated to support prerelease items. In the Items page, a new dropdown under “Filter By” gives control over whether or not to list prerelease items. The options available are “Include Prerelease”, and “Stable Only”.

PowerShell Gallery prerelease filter

Additional changes appear on the pages for individual items. If an item is a prerelease, there will be a banner at the top of the page stating that this is a prerelease version:

PowerShell Gallery prerelease item banner

The following banner was added to show that the current item is the latest stable version of an item, but a prerelease item exists with a higher version:

PowerShell last stable item banner

Finally, the item history on the same page has been updated to show the latest stable (or non-prerelease) version available, as shown below:

PowerShell Gallery prerelease item history

Some important things to note:
  • If -AllowPrerelease is not specified, the behavior of the cmdlets is the same as one would see with older versions of PowerShellGet: no prerelease versions will be returned. This ensures these changes are backwards compatible with previous PowerShellGet versions.
  • This change only affects the PowerShellGet cmdlets and the PowerShell Gallery. As of the writing of this blog, PowerShell does not support prerelease strings in version identifiers, so prerelease strings are provided as a separate element in the module manifest.
  • There are limitations on what the prerelease string can contain, see the Documentation for more details. 
  • Prerelease support follows the SemVer v1.0.0 guidelines. We chose to align with SemVer 1.0.0 to maintain parity with the current NuGet server used by many of our customers as an on-premise gallery.
To start using prerelease versions in your modules and scripts with the PowerShell Gallery, update to the latest PowerShellGet moduleYou must install the update in order to use the -AllowPrerelease flag, which is required for finding or downloading any prerelease items in the PowerShell Gallery. 

ESXi 6.5.0 Web client stop accepting connection from different PC

This post was originally published on this site

I have a ESXi 6.5.0 running for a few months and everything was great. It has approximately 11 VM up and running.

However, recently I noticed that only 1 PC on the network can access the Web client using URL

I restarted the host and it went back to normal of which all other PC on the network will have access to it. But few days later, problem will come back.

For the PC that can not access Web Client, I can ping the server no problem at all and I have tried all browsers (IE, Edge, Chrome and Firefox) but it shows page can’t be displayed.

It’s talking to the web client somehow because it changes the icon as following.

I know host restart will fix this but it’s annoying to keep on restarting the host. Is there a service that I can restart and try?

Is there any other way to connect to the host?

What else might be wrong with my server?

Thanks for any help.