로컬 혹은 원격 서버의 패스워드를 변경하기 위한 방법

출처 : http://community.spiceworks.com/how_to/1966-how-to-change-local-user-or-admin-passwords-on-remote-computers

Steps (4 total)

1

Obtain PSTools

You can get PSTools from http://technet.microsoft.com/en-us/sysinternals/bb896649

2

Open the Command Console

To open the Command Console 
1. Click on Start 
2. Click on “Run” 
3. Type “CMD” in the “Run” box. 
4. Change the prompt to the PSTools folder by typing the full folder path. Example: C:\Blabla\PSTools

3

For a single computer

Inside the Command Console type: 

pspasswd.exe \\Remote_computer_name -u user_name -p new_password

Obviously you would replaced Remote_computer_name with the name of your remote PC, user_name with the actual username, and new_password with the actual new password for that user.

4

For a multiple computers:

Expand

1. Create a text file named PCs.txt or whatever you want .txt with the names of the PCs to change a given local user’s password. One computer name per line, no spaces or extra lines.

2. Save the text file in the PSTools folder for convenience or you’ll have to type the full file path in the command.

3. Inside the Command Console type: 
pspasswd.exe @pcs.txt -u user_name -p new_password

Conclusion

And that is all folks.
Visit http://technet.microsoft.com/en-us/sysinternals/bb897543 for more info.

PsPasswd v1.23

By Mark Russinovich

Published: October 17, 2012

 Download PsTools (1.6 MB)

Rate:

Share this content

 

 

 

 

 

 

Introduction

Systems administrators that manage local administrative accounts on multiple computers regularly need to change the account password as part of standard security practices. PsPasswd is a tool that lets you change an account password on the local or remote systems, enabling administrators to create batch files that run PsPasswd against the computers they manage in order to perform a mass change of the administrator password.

PsPasswd uses Windows password reset APIs, so does not send passwords over the network in the clear.

 

Installation

Just copy PsPasswd onto your executable path, and type "pspasswd" with the command-line syntax shown below..

 

Using PsPasswd

You can use PsPasswd to change the password of a local or domain account on the local or a remote computer.

usage: pspasswd [[\\computer[,computer[,..] | @file [-u user [-p psswd]]] Username [NewPassword]

computer	Perform the command on the remote computer or computers specified. If you omit the computer name the command runs on the local system, and if you specify a wildcard (\\*), the command runs on all computers in the current domain.
@file	Run the command on each computer listed in the text file specified.
-u	Specifies optional user name for login to remote computer.
-p	Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.
Username	Specifies name of account for password change.
NewPassword	New password. If ommitted a NULL password is applied.

 

Download PsTools
(1.6 MB)

Windows 8 or 2012에서

John Marlin [MSFT]

John Marlin [MSFT]

Microsoft Corporation

MSFT

4,399 Points 3 2 0

Recent Achievements

Blog Conversation Starter Blogger II New Blog Rater

View Profile

With each new release of Windows, it's a challenge to balance keeping the OS footprint small with maintaining forward compatibility for applications and devices. The .Net Framework is at the heart of this challenge. In Windows 8, Microsoft decided to take a new approach to the way that such features are installed. In this post, I will describe the new approach, how the changes might affect you, and how you can prepare for them to ensure a smooth transition to Windows 8.

About the .Net Framework

The .Net Framework provides a class library and a Common Language Runtime (CLR) that allow software developers to create rich, secure applications. Additionally, the Framework provides the functionality required for such applications to run. A program developed using a particular version of the Framework typically requires that version, or a compatible one, to be installed on computers where it will run.

Windows 7 and Windows Server 2008 R2 included .Net Framework 3.5. Additionally many applications have been written using .Net 4.0, so that version is often installed using a redistributable package from Microsoft. Windows 8 and Windows Server 2012 include .Net 4.5, which supports building and running the next generation of applications and web services, including Metro-style apps. .Net 4.5 supports applications written for 4.0, so there is no need to install .Net 4.0 on Windows 8.

Features on Demand (FoD)

"Features on Demand (FoD)" is a new concept in Windows 8 that allows administrators and image builders to reduce the amount of space used by the component store by adding only the payload for optional components they need to a system image. "Payload" refers to the binaries and other files associated with a feature. Features on Demand also allows for the addition of roles and features to an image at any time they are needed .

In Windows 8,.Net Framework 3.5 is now a Feature on Demand. And to simplify the installation of common legacy versions of the .Net Framework, .Net 3.0 and 2.0 have been included in the same feature package as 3.5. That means if any of those three versions need to be installed, all the administrator needs to do is enable the single .Net Framework 3.5 feature in Windows 8.

While we encourage developers to create or upgrade their applications using .Net 4.5, we realize that many commonly-used apps exist that depend on older versions of .Net, and that it takes time for developers to upgrade their code and for customers to upgrade to the new apps. For these reasons we have provided a variety of methods by which customers can enable the legacy versions of .Net in Windows 8.

Installation Sources

The .Net Framework 3.5 payload can be obtained from any of the following sources:

· Windows Update (WU)

· A Windows Image file (.wim) to which the payload has been added

· The \sources\sxs folder on the installation media

There are unique advantages to using each. The source can be specified for the environment using a new Group Policy setting. It can also be specified when installing .Net 3.5 manually on an individual machine or image.

The simplest scenario is one in which WU is accessible to both the machine and the user, and the machine is not configured to obtain updates from Windows Server Update Services (WSUS). In this case, when the feature is enabled, the user will be prompted for permission to download the update. If permitted, Windows will download the payload directly from Windows Update and install the feature. Done!

In more controlled environments, administrators might want to redirect such download requests to an alternate source such as a Windows Image file (.wim) to which the payload was added, or the\sources\sxs folder from the installation media. There might also be network , proxy, or security configurations that prevent users from directly accessing Windows Update. Additionally, WSUS does not currently support the payloads for Features on Demand, although it does support the subsequent patching of the features. So in environments where machines are configured to obtain updates from WSUS, administrators will need to configure the source for initial FoD installations.

To allow administrators to manage these scenarios, a new Group Policy setting was introduced in Windows 8 / Windows Server 2012: "Specify settings for optional component installation and component repair”, located under Computer Configuration\Administrative Templates\System:

This policy allows the administrator to configure the installation of Features on Demand and feature store repair operations to use only authorized locations.

When this policy is enabled, a network location (for example, a file server) can be specified for both repair of the feature store, and enabling features whose payloads were not originally added. The Alternate source file path can point to a \sources\sxs folder or a Windows image (WIM) file using the WIM: prefix. The repair WIM can be different than the initial WIM file used for installation. You can specify multiple paths by using ";" between the paths. Valid syntax is "wim:<path to wim>:<index>". Or "<path to sxs folder>".

Examples:

\\server\Win8Media\sources\sxs

wim:\\server\sourcewim\install.wim:3

If you select Never attempt to download payload from Windows Update, WU is not contacted during an installation or repair operation.

If you select Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS), attempts to add features (for example, .NET Framework 3.5) or repair the feature file store use Windows Update to download files. Target computers require Internet and WU access for this option. Normal servicing operations continue to use WSUS if it has been configured as a source.

The advantage of a WIM file is that it can be kept current with updates. This may be important because files associated with features that have post-RTM updates will be repaired to their current versions if the specified source contains the current updates. It is important to note however, that the initial installation of FoDs from an updated WIM will still use RTM versions of files, with subsequent updates being applied using standard patching sources such as WU or WSUS. I'm not going to cover how to create and maintain a WIM file here. For more information on how to do that see Deployment Image Servicing and Management (DISM) Technical Reference .

The\sources\sxs folder on the installation media can provide a quick and easy local source for initial installations. In addition to referencing the sxs folder in the policy setting above, you can specify it as the source for manually installation on individual machines. To make the source files available on the internal network, use the XCOPY command to copy the source files to a network share, and then reference the share as a mapped drive or a UNC where applicable:

xcopy d:\sources\sxs\*.* x:\Win8Media\sources\sxs\ /s

Installation Methods

Now that we have covered the various sources, let's talk about how to enable the feature. There are three basic ways .Net 3.5 can be enabled, in order of preference: proactively, manually, or automatically.

By far, the most hassle-free way to install any FoD to more than a very few machines is to add the payload and enable the feature on images you will be deploying in your environment. Couple that with configuring the Group Policy setting mentioned earlier to point to the right source for one-off scenarios, and about the only administrative work you will have beyond that will be maintaining an updated WIM file for feature repair. Again, I am not going into details here about how to create images for broad deployment. For more information on how to do that see Deployment Image Servicing and Management (DISM) Technical Reference.

The simplest way to enable .Net 3.5 on a small number of Windows 8 client machine is through Turn Windows features on or off:

1. On the Start Screen begin typing “turn windows features on or off”, select Settings in the search pane, and click on Turn Windows features on or off.

2. Check the box next to .Net Framework 3.5 (includes .NET 2.0 and 3.0)

3. The wizard will search for required files and then prompt you to download files from Windows Update.

4. Select Download files from Windows Update.

5. After the wizard completes, click Finish.

The process on Windows Server 2012 is similar but is accomplished using the Add Roles and Features Wizard:

1. In Server Manager, click Manage, then select Add Roles and Features.

2. Click Next at the Before you begin screen.

3. At the Select installation type screen, select Role-based or feature-based installation and click Next.

4. On the Select destination server screen, select the target server and click Next.

5. On the Select server roles screen, click Next.

6. On the Select features screen, check the box next to .Net Framework 3.5 Features and click Next. If you expand the tree it looks like this:

7. On the Confirm installation selections screen, a warning will be displayed asking "Do you need to specify an alternate source path?...". If the target machine does not have access to Windows Update, click the Specify an alternate source path link to specify the path to the \sources\sxs folder and click OK:

8. After you have specified the alternate source, or if the target machine has access to Windows Update, click Install.

Note that the Add Roles and Features Wizard gives the administrator the option to specify an alternate resource, whereas the Turn Windows features on or off dialog does not. In most environments, administrators will deploy standard images of client machines that include the necessary features, or they will configure Group Policy to specify the installation source for Features on Demand.

Administrators can also use Deployment Image Servicing and Management (DISM) or Powershell cmdlets to enable the feature. DISM can be used to install the feature on individual computers, or to install it on an image that will be deployed to multiple computers.

Here are some sample DISM commands to enable and get the status of the .Net Framework 3.5 feature:

Dism /online /get-featureinfo /featurename:NetFx3

Dism /online /enable-feature /featurename:NetFx3 /All

Dism /online /enable-feature /featurename:NetFx3 /All /LimitAccess /Source:x:\sources\sxs

Use /All to enable all parent features of the specified feature

Use /LimitAccess to prevent DISM from contacting WU/WSUS

Use /Source to specify the location of the files needed to restore the feature.

(x: is the drive letter of the installation media or mapped network share that contains a copy of the installation files)

To install using Powershell, use Server Manager cmdlets on servers to install features. (It should be noted that the Get-WindowsFeature cmdlet may not show a feature as installed unless all of its parent features are also installed):

Get-WindowsFeature –name NET-Framework-Core

Install-WindowsFeature –name NET-Framework-Core

Install-WindowsFeature –name NET-Framework-Core –source x:\sources\sxs

Similar DISM Powershell cmdlets can be used on either client or server, but note again that the Server manager cmdlets above are recommended on server..

Get-WindowsOptionalFeature –Online –FeatureName NetFx3

Enable-WindowsOptionalFeature –Online –FeatureName NetFx3 –All

Enable-WindowsOptionalFeature –Online –FeatureName NetFx3 –All -LimitAccess -Source x:\sources\sxs

Windows features that require .Net 3.5

As of this writing, the only Windows feature I am aware of that requires .Net 3.5 (beyond those that are specific to .Net 3.5 and ASP.Net 3.5) is Powershell 2.0. If you need it for script compatibility, you will need to install .Net 3.5 to get Powershell 2.0 functionality. On Windows 8 client, Windows PowerShell 2.0 is already enabled and you simply need to enable .Net 3.5 to use it. On server, you will need to install the Windows PowerShell 2.0 Engine, which will prompt you to also install .Net 3.5.

Applications

The automatic installation trigger I alluded to earlier requires a discussion about installing applications.

As mentioned before, many applications rely on older versions of the .Net Framework. In fact, some current versions of Microsoft products including Microsoft SQL and some System Center products use older versions.

Many applications perform checks during their installation to verify that the required version of the .Net Framework is installed. If not, they install the necessary version, often using a redistributable package available from Microsoft. However, the methods that application installers use to verify and install .Net can vary. The experience of installing apps in Windows 8 might have unexpected results because of how external attempts to install .Net are now intercepted and handled by Windows.

Installation of the new.Net Framework 3.5 FoD package can be triggered automatically in Windows 8 in the following scenarios:

· You attempt to install .Net 2.0, 3.0, or 3.5 using a redistributable package available for download from Microsoft.

· An application attempts to install one of the redistributable packages for a required version during its own installation process.

· An application that requires a legacy version, executes without preinstalling the required version.

In each of these cases, an application shim in Windows 8 intercepts the attempt and invokes the installation of the new .Net 3.5 feature. Once triggered, the installation should proceed as if it was initiated from the UI, DISM, or Powershell.

The classic "Your mileage may vary" disclaimer applies here because we really don't know how all applications will react to the shim intercepting the installation attempt. Also, some apps look for the existence of certain files to verify the installation of the desired .Net version. Such app installations may fail if .Net 3.5 was preinstalled because some files previously present on the older versions have been deprecated in Windows 8. We are however testing many frequently used apps, and in some cases introducing pre-app shims if they are detecting .NET inappropriately.

To avoid problems with applications that need it, it is best to enable the new .Net 3.5 feature before installing your app.

Recommendations

As with anything else, a little planning can go a long way. Here are the steps I recommend you consider in order of importance:

A. Understand and evaluate the requirements of your applications. Don't just assume that every computer will require .Net 3.5 and enable it on all of your images. Doing this will defeat the potential benefits of having the payload removed. By the same token, if you deploy Windows 8 with the intention of dealing with the users and computers that need .Net 3.5 as they come up, you are setting yourself and your helpdesk up for a lot of unnecessary hassle. Install all of your common LOB and infrastructure apps one at a time in a test environment without .Net 3.5 and observer whether they attempt to install an older version of the Framework, and in general how they function. Then enable .Net 3.5 and make sure all apps function as expected.

B. Include .Net 3.5 in images that will be deployed to users that will likely be running apps that require it.

C. Copy the files from the installation media to a network share to so they can be referenced by manual installation attempts and optionally by the new Group Policy setting.

D. Regardless of whether your environment includes WSUS servers, treat configuring the new Group Policy setting as a requirement. You should determine how you want to handle attempts to download not only .Net 3.5, but also other Features on demand. Additionally, as the name implies, the policy also tells Windows where to obtain files to repair the feature store.

E. Create and maintain a Windows Image that can be referenced by the Group Policy setting for ongoing FoD and feature store repair downloads.

F. Experiment with the DISM Powershell cmdlets to be prepared to deploy Features on Demand remotely to machines as needed.

Misc. Considerations

Upgrading from Windows 7 / Windows Server 2008 R2

When a PC running Windows 7 (which includes .NET Framework 3.5.1 by default) is upgraded to Windows 8, or when a server running Windows Server 2008 R2 (which has .NET Framework 3.5.1 feature installed) is upgraded to Windows Server 2012, .NET Framework 3.5 is enabled automatically using the files on the installation media. The purpose of this is to increase the chances that all apps will work as they did before the upgrade.

Multilingual images

For images that will support more than one language, it is best to add the .NET Framework 3.5 binaries before adding any language packs. This order ensures that .NET Framework 3.5 language resources are installed correctly within the reference image and available to users and applications.

Common Problems

Here, I've included three issues that you might run into when installing .Net 3.5. The hex error code is the most recognizable part and uniquely identifies each error. I've also included variations on text that might accompany the error code to increase the discoverability of this post. The text will vary, depending on whether it occurs on Windows 8 or Windows Server 2012, whether you tried to install it using the UI, DISM, or PowerShell, and on the build (Developer Preview, Consumer Preview, Release Preview, etc.):

0x800F0906 - CBS_E_DOWNLOAD_FAILURE

Windows couldn't complete the requested changes.

Windows couldn't connect to the Internet to download necessary files. Make sure you are connected to the Internet, and press 'Retry' to try again.

Windows couldn't connect to the Internet to download necessary files. Make sure you're connected to the Internet, and press 'Retry' to try again.

Error code: 0x800F0906

The request to add or remove features on the specified server failed.

Installation of one or more roles, roles services, or features failed.

The source files could not be downloaded.

The source files could not be found.

Use the /source option to specify the location of the files that are required to restore the feature. The file location should be either the root directory of a mounted image or a component store that has the Windows Side-by-Side directory as an immediate subfolder.

Use the "source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077.

Try installing the roles, role services, or features again in a new Add Roles and Features Wizard session, and on the Confirmation page of the wizard, click "Specify an alternate source path" to specify a valid location of the source files that are required for the installation. The location must be accessible by the computer account of the destination server.

This is the most common issue that occurs when attempting to install .Net 3.5. It stems from the machine or user not having access to a configured payload source.

To resolve this issue, make sure the machine and user have access to Windows Update, or that you have configured an alternate source to which the user and machine have access in the Group Policy setting. If machines in your environment are configured to use WSUS, make sure you have configured the Group Policy setting to direct download requests to WU or an alternate source. If it continues to fail, use the DISM command or Powershell cmdlet to install the feature, pointing to a local installation source.

0x800F081F - CBS_E_SOURCE_MISSING

(The text for this message is often similar to that of the 0x800F0906 error above.)

This can occur when trying to install from an installation source that is corrupt, incomplete, or invalid for the installed build (for example trying to use a Windows 8 Developer Preview source for a Consumer Preview or RTM installation). Also, make sure the full path is correct (x:\sources\sxs) and that the user has at least READ access to the location. Try to access the source directly as the installing user from the affected machine.

0x800F0907 - CBS_E_GROUPPOLICY_DISALLOWED

DISM failed. No operation was performed. For more information, review the log file. The DISM log file can be found at %WINDIR%\logs\DISM\dism.log.

Due to network policy settings, Windows couldn't connect to the Internet to download files required to complete the requested changes. Please contact your network administrator for more information.

This might occur if Group Policy has been configured to prevent installing .NET Framework 3.5 from Windows Update. To resolve this, configure an alternate source in the new Group Policy setting.

References

How to Enable or Disable Windows Features

(How to) Configure a Windows Repair Source

Microsoft .Net

.Net Framework Developer Center

.NET Framework 3.5.1 Features Overview

Deployment Image Servicing and Management (DISM) Technical Reference

How to Mount and Modify an Image

How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site

Jim Martin

Senior Support Escalation Engineer

Microsoft Platforms Core Support