Cleanup $NTServicePackUninstall$ and SoftwareDistribution Folder

Service pack and Windows update installations leave a lot of unnecessary files in the %SystemRoot% folder. They occupy a lot of space and you can safely delete these files. Do this only when you are sure that you will not need to uninstall any of the updates or Service Pack.

To remove the Service Pack uninstall files
  1. Go to C:\WINDOWS and delete "$NTServicePackUinistall$"
  2. Go to Add/Remove Programs.
  3. Click "Service Pack 1"(2)(3), there will be an error since you just deleted the file.
  4. Click YES to delete the shortcut.
  5. Use similar procedure to delete uninstall files for the updates.

The updates will be in this format "$NTUninstall********"
Do NOT delete "$hf_mig$"

To remove the Automatic updates’ files in SoftwareDistribution Folder

Automatic updates are downloaded in %systemroot%\SoftwareDistribution\Download folder and occupy a lot of space. You can safely delete these files.

  1. Open a command prompt window
  2. type net stop wuauserv and press enter
  3. Open Windows Explorer and delete all contents in the folder c:\windows\SoftwareDistribution\Download
  4. Go back to Command prompt window and type net start wuauserv and press enter

Be sure to restart Windows before before another attempt at getting the updates !!

——————–End of Document —————-

Tags: Windows Server 2003, Windows Server 2008, Windows XP

Published Date: 20080519

Advertisements

Basic configuration of Windows Server 2008 core via CLI commands

To set the server with a static IP address

1. At a command prompt, type the following:

netsh interface ipv4 show interfaces

2. Look at the number shown in the Idx column of the output for your network adapter. If your computer has more than one network adapter, make a note of the number corresponding to the network adapter for which you wish to set a static IP address.

3. Type the following

netsh interface ipv4 set address name="<ID>" source=static address=<StaticIP> mask=<SubnetMask> gateway=<DefaultGateway>

netsh interface ipv4 add dnsserver name="<ID>" address=<DNSIP> index=1

To set the administrative password in Windows Server 2008

1. Type the following at the command prompt:

net user administrator *

2. When prompted to enter the password, type the new password for the administrator user account and press ENTER

3. When prompted, retype the password and press ENTER.

To change the name of the server

1. Determine the current name of the server with the hostname or ipconfig /all commands.

2. Type the following at the command prompt:

netdom renamecomputer <ComputerName> /NewName:<NewComputerName>

3. Restart the computer by typing the following at a command prompt: shutdown /r /t 0

Add or Remove a user to the local Administrators group

net localgroup Administrators /add [domain]\[username]

net localgroup Administrators /delete [domain]\[username]

To manage a server running a Server Core installation by using the Windows Remote Shell

1. To enable Windows Remote Shell on a server running a Server Core installation, type the following command at a command prompt:

WinRM quickconfig

2. Click Y to accept the default settings. Note: The WinRM quickconfig setting enables a server running a Server Core installation to accept Windows Remote Shell connections.

3. On the remote computer, at a command prompt, use WinRS.exe to run commands on a server running a Server Core installation. For example, to perform a directory listing of the Windows folder, type:

winrs -r:<ServerName> cmd

To activate the server, at a command prompt, type:

slmgr.vbs –ato

If activation is successful, no message will return in the command prompt. To activate the server remotely type the following at the command prompt:

cscript slmgr.vbs -ato <servername> <username> <password>

Retrieve the GUID of the computer by typing:

cscript slmgr.vbs -did

Verify that License status is set to Licensed (activated).

cscript slmgr.vbs -dli <GUID>

To join or remove a Windows 2008 server to a domain, at a command prompt, type:

netdom join <ComputerName> /domain:<DomainName> /userd:<UserName> /passwordd:*

netdom remove <ComputerName> /Domain:<DomainName>

Restart the server to complete the operation

Enable ICMP Replies (via local Command Prompt)

1. On your Server Core machine, at a command prompt, type the following

netsh firewall set icmpsetting 8

2. You can always run the following command in order to disable this option:

netsh firewall set icmpsetting 8 disable

Enable ICMP Replies (via Windows Firewall Management Snap-in from a remote computer)

1. You will first have to enable the Server Core server to allow remote Windows firewall Management connections. To do so, please follow the steps outlined below.

2. After performing the below steps, you will be able to enable or disable any Firewall rule from the remote snap-in.

3. In order to enable ICMP Echo Replies from the Server Core server, allowing the administrators to test for connectivity issues with the server, go to Inbound Rules.

4. In the results pane scroll down till you find File and Printer Sharing (Echo Request – ICMPv4-In), right-click it and choose Enable.

Enable ICMP Replies (via the Windows Remote Shell)

1. To enable Windows Remote Shell on a server running a Server Core installation, type the following command at a command prompt:

WinRM quickconfig

2. Click Y to accept the default settings.

3. On the remote computer, at a command prompt, use WinRS.exe to run commands on a server running a Server Core installation. For example, to perform a directory listing of the Windows folder, type:

winrs -r:<ServerName> cmd

4. You can now type the command :

netsh firewall set icmpsetting 8

Enable remote management through the firewall

1. On your Server Core machine, at a command prompt, type the following:

netsh advfirewall set currentprofile settings remotemanagement enable

2. You can always run the following command in order to disable this option:

netsh advfirewall set currentprofile settings remotemanagement disable

3. Open the Windows Firewall snap-in on a remote computer running Windows Server 2008 or Windows Vista, click Start > Run, then type MMC and press ENTER.

4. Click File > Add/Remove Snap-in. In the Add or remove snap-ins, scroll down till you find the Windows Firewall with advanced security snap-in.

5. Click Add, then in Another Computer, type the name or IP Address of the Server Core server you want to manage.

6. After a short loading, if all is ok, you will be presented with the management GUI of the remote server. You can now create new Firewall rules, enable or disable existing rules, export your settings or disable the Firewall altogether.

7. For example, to enable the rule allowing Remote Desktop connections to the Server Core, go to Inbound Rules. In the results pane scroll down till you find Remote Desktop (Tcp-in), right-click it and choose Enable.

————– End of Document —————–

Tags: Windows Server 2008

Published Date: 20080404

How to disable IPv6 stack on Windows Server 2008 core

Unlike Windows XP and Windows Server 2003, IPv6 in Windows Vista and Windows Server 2008 cannot be uninstalled. However, you can disable IPv6 in Windows Vista and Windows Server 2008 by doing one of the following:

Windows Server Core:

1. Export the registry key

reg export hklm\system\currentcontrolset\services\tcpip6\parameters c:\regipv6.txt

2. Add the following key under parameters using the command mentioned below

reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255

Windows Server Full installation:

1. In the Network Connections folder, obtain properties on all of your connections and adapters and clear the check box next to the Internet Protocol version 6 (TCP/IPv6) component in the list under “This connection uses the following items”.

This method disables IPv6 on your LAN interfaces and connections, but does not disable IPv6 on tunnel interfaces or the IPv6 loopback interface.

2. Add the following registry value (DWORD type) set to 0xFF:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents

This method disables IPv6 on all your LAN interfaces, connections, and tunnel interfaces but does not disable the IPv6 loopback interface. You must restart the computer for this registry value to take effect.

If you disable IPv6, you will not be able to use Windows Meeting Space or any application that relies on the Windows Peer-to-Peer Networking platform or the Teredo transition technology.

Please do have a look at the article http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx before making any changes to the system to know about the effects on the system.

————– End of Document —————–

Tags: Windows Server 2008

Published Date: 20080403

Managing Telnet Server service in Windows Server 2008 using CLI

To install Telnet client or server use one of the following commands

Full Installation:

Servermanagercmd –install telnet-server

Servermanagercmd –install telnet-client

Core Installation:

Ocsetup TelnetServer (case sensitive)

Ocsetup TelnetClient (case sensitive)

Note: After installation the Telnet Server service is disabled and in stopped mode. You need to manaually enable it and start the service. No confirmation message is displayed before or after completion of installation

To uninstall Telnet client or server use one of the following commands

Full Installation:

Servermanagercmd –remove telnet-server

Servermanagercmd –remove telnet-client

Core Installation:

ocsetup TelnetServer /uninstall (case sensitive)

ocsetup TelnetClient /uninstall (case sensitive)

To verify if the Telnet Client and/or server is installed on the server:

Full Installation:

Servermanagercmd –q

Core Installation:

oclist

————– End of Document —————–

Tags: Windows Server 2008

Published Date: 20080401

Manage Windows Server 2008 or Windows Vista remotely using WMI

WMI is a core Windows management technology that administrators can use to write scripts to perform administrative tasks on both local and remote computers. There are no specific enhancements to WMI in Windows Server 2008 beyond those included in Windows Vista, but it’s important to know about the Windows Vista enhancements since these apply to Windows Server 2008 also. Here are a few of the more significant changes to WMI in Windows Vista and Windows Server 2008:

· Improved tracing and logging: The WMI service now uses Event Tracing for Windows (ETW) instead of the legacy WMI log files used on previous Windows platforms, and this makes WMI events available through Event Viewer or by using the Wevtutil.exe command-line tool.

· Enhanced WMI namespace security: The NamespaceSecuritySDDL qualifier can now be used to secure any namespace by setting WMI namespace security in the Managed Object Format (MOF) file.

· WMI namespace security auditing: WMI now uses the namespaces system access control lists (SACL) to audit namespace activity and report events to the Security event log.

· Get and Set security descriptor methods for securable objects: New scriptable methods to get and set security descriptors have been added to Win32_Printer, Win32_Service, StdRegProv, Win32_DCOMApplicationSetting, and _SystemSecurity.

· Manipulate security descriptors using scripts: The Win32_SecurityDescriptorHelper class now has methods that allow scripts to convert binary security descriptors on securable objects into Win32_SecurityDescriptor objects or Security Descriptor Definition Language (SDDL) strings.

· User Account Control: (UAC) affects what WMI data is returned, how WMI is remotely accessed, and how scripts must be run.

What all this basically means is that WMI is more secure and more consistent in how it works in Windows Server 2008, which is good news for administrators who like to write WMI scripts to manage various aspects of their Windows-based networks. Still writing WMI scripts isn’t always easy, especially if you’re trying to get them to run properly against remote machines. Windows Vista and Windows Server 2008 complicate things in this regard because of their numerous security improvements, including User Account Control (UAC). So it’s instructive to listen to one of the experts at Microsoft, who will address this very issue in detail.

From the Experts: WMI Remote Connection

Before looking at the UAC aspects, let step back and look at the requirements to call WMI remotely. This applies to any Windows platform since Windows 2000. We will examine the Windows Vista and Windows Server 2008 aspects next.

To connect remotely, four conditions must be met:

1. Firewall Introduced with Windows XP, the Windows Firewall must be properly set up to enable connectivity for the WMI RPC traffic. Usually, you get an "RPC connection failure" if the Windows Firewall is enabled and RPC is disallowed. If you get an "access denied" message, the firewall is not the root cause of the issue. Keep in mind that the firewall is the key component to go through before anything else happens. Before Windows Vista and Windows Server 2008, RPC traffic must be enabled to allow the WMI traffic to go through. With Windows Vista and Windows Server 2008, a dedicated set of Firewall WMI rules is available to enable only WMI traffic. (This can be done with the FW.MSC MMC snap-in, Group Policies, Scripting, or NETSH.EXE.) Note that if you use WMIDiag (available on Microsoft Download Center), it will tell you which NETSH.EXE command to use to configure your firewall properly.

2. DCOM Once the firewall gate is passed, it is time to consider the DCOM security. The user issuing the remote call must have the right to "Launch and Activate" (which can be viewed and changed with DCOMCNFG.EXE) for both the My Computer and Windows Management and Instrumentation objects. By default, only users who are part of the Administrators group of the remote machine have the right to remotely "Launch and Activate" these DCOM objects.

3. WMI namespace Once the DCOM security is verified, WMI namespace security comes next. In this case, the user connecting to a remote WMI namespace must have at the minimum the Enable Remote and Enable Account rights granted for the given namespace. By default, only users who are part of the Administrators group of the remote machine have the Enable Remote right granted. (This can be updated with WMIMGMT.MSC.)

4. Manageable entity Last but not least, once WMI has accepted the remote request, it is actually executed against the manageable entity (which could be a Windows Service or a Terminal Server configuration setting, for instance). This last step must also succeed for the WMI operation to succeed. WMI does not add any privilege that the user does not have when issuing the WMI request. (By default, WMI impersonates the calls, which means it issues the call within the security context of the remote user.) So, depending on the WMI operation requested and the rights granted to the remote user, the call might succeed or fail at the level of the manageable entity. For instance, if you try to stop a Windows service remotely, the Service Control Manager requires the user to be an Administrator by default. If you are not, the WMI request performing this operation will fail.

This describes the behavior of WMI since Windows 2000. In the light of Windows Vista and Windows Server 2008, things can be slightly different because UAC is enabled by default on both platforms and everything depends on whether you use a local account or a domain account. If you use a local user of the remote machine who is a member of the Local Administrators group, the Administrators membership of the user is always filtered. In this context, DCOM, WMI, and the manageable entity are applying the security restrictions with respect to the filtered token presented. Therefore, with respect to the UAC behavior, the token is a user token, not an administrative token! As a consequence, the Local User is actually acting as a plain user on that remote machine even if it is part of the Local Administrators group. By default, a user does not have the rights to pass the security gates defined earlier (in step 2, 3, and 4).

Now that the scene is set, how do you manage a remote Windows Vista machine or 2008 server while respecting the Firewall, UAC, DCOM, WMI, and manageable entity security enforcements?

This challenge must be looked at in two different ways:

1. The remote machine is part of a domain: If the remote machine is part of a domain, it is highly recommended that you use a Domain User part of the Local Administrators group of the remote machine (and not a Local User part of the Local Administrators group). By doing so, you will be a plain Administrator because UAC does not filter users out of the Local Administrators group when the user is a Domain User. UAC only filters Local Users out of the Local Administrators group.

2. Your machine is a workgroup machine: If your machine is in a workgroup environment, you are forced to use a Local User part of the Local Administrators group to connect remotely. Obviously, because of the UAC behavior, that user is filtered and acts as a plain user. The first approach if you are in a large enterprise infrastructure is to consider the possibility of making this machine part of a domain to use a Domain User. If this is not possible because you must keep the machine as part of a workgroup, from this point you have two choices:

o You decide to keep UAC active. In this case, you must adjust the security settings of DCOM and WMI to ensure that the Local User has the explicit rights to get remote access. Don’t forget that a best practice is to use a dedicated Local Group and make this Local User a member of that group. In this context, the WMI requests against the manageable entity might work or not depending on the manageable entity security requirements (discussed in step 3). If the manageable entity does not allow a plain user to perform the task requested, you might be forced to change the security at the manageable entity level to explicitly grant permissions to your Local User or Group as well. Note that this is not always possible because it heavily depends on the manageable entity security requirements and security management capabilities of the manageable entity. For the Windows Services example, this can be done with the SC.EXE command via an SDDL string, the Win32_Service WMI class (with the Get/SetSecurityDescriptor methods implemented in Windows Vista and Windows Server 2008), or Group Policies (GPEDIT.MSC). By updating the security at these three levels, you will be able to gracefully pass the DCOM and WMI security gates and stop a Windows Service as a plain user. Note that this customization represents clearly the steps for a granular delegation of the management. Only the service you changed the security for can be stopped by that dedicated user (or group). In this case, you actually define a very granular security model for a specific task. (You can watch the "Running Scripts Securely While Handling Passwords and Security Contexts Properly" webcast at http://go.microsoft.com/fwlink/?LinkId=39643 to understand this scenario better.) Now it is possible that some manageable entities only require the user to be an Admin (typical for most devices) because there is no possibility to update the security descriptor. In such a case, for a workgroup scenario, only the second option (discussed next) becomes possible. Last but not least, keep in mind that these steps are also applicable in a domain environment to delegate some management capabilities to a group of domain users.

o You decide to disable the UAC filtering for remote access. This must be the last-resort solution. It is not an option you should consider right away if you want to maintain your workgroup system with a high level of security. So consider it only after investigating the possibility of making your system part of a domain or after reviewing the security wherever needed. If making your system part of a domain is not possible, you can consider this option. In this case, you must set the registry key in the reference shown below to ZERO on the remote system. Note that you must be an administrator to change that registry key. So you need to do this locally once, before any remote access is made. Note that this configuration setting disables the filtering on Local Accounts only; it does not disable UAC as a whole.

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]"Local AccountTokenFilterPolicy"=dword:00000001

Once set, the registry key is created and set to ONE, and the Local User remotely accessing the machine will be an administrator (if the user is a member of the Local Administrators group).Therefore, by default, the user will pass the security gates defined in steps 2, 3, and 4. Note that it is required to reboot the machine to get this change activated.

————– End of Document —————–

Tags: Windows Vista, Windows Server 2008

Published Date: 20080304