Archive for the ‘Windows 7’ Category

Disable WSUS on Managed Computers

The past 8 or more years most of us have managed PC updates using WSUS (Windows Server Update Service) and Group policy.  However, the structure of the modern office has changed to a large percentage of mobile employees who never ‘touch down’ at headquarters.   If these devices do not connect to the domain they do not have updates applied.

A client who has not returned to the office in 18 months, and likely will not for the life of their laptop, recently asked how they could update their machine manually.  Currently they were not able to do so as Windows Update showed “settings are managed by your system administrator”, in other words, by WSUS

image

It is quite simple to disable WSUS management in the registry, however remember if the device is reconnected to the domain, the WSUS policies will be reapplied.  Therefore you may want to move the device to an OU not linked to the WSUS policy or remove the device in the policy under security filtering.

Disclaimer:  Be aware making incorrect registry changes can have disastrous effects to the health of the device.  Be sure to backup the registry before editing.  To do so see the following Microsoft article; “How to back up and restore the registry in Windows”  http://support.microsoft.com/kb/322756 

  • Open the registry editor, by entering Regedit in the Start / Run box, and browse to:  HKLM\Software\Policies\Microsoft\Windows\
  • Locate the WindowsUpdate  Key and delete it
  • Reboot the PC (may take 2 reboots)
  • Now you can manually update and configure Windows updates to automatically check for and install updates directly from the Microsoft Update site

image

You may want to consider using a newer service such as Windows Intune to manage your computers, especially mobile devices.  http://www.microsoft.com/en-us/server-cloud/products/windows-intune/

Multiple RDP Sessions on a PC –legal or not

There are many web sites outlining how to reconfigure windows XP, Vista, and Windows 7 to allow multiple concurrent Remote Desktop Sessions, basically making a desktop PC a terminal server. On many occasions I have pointed out doing so is a licensing violation, however I confess I have never seen this specifically stated in any ELUA.  I have been privy to discussions with Microsoft where this has been discussed, and Microsoft employees and support site personnel have often posted it is not permitted on various  sites.

Having been asked to verify this I reviewed various EULAs (End User Licensing Agreements) and it seems Microsoft more often explains in detail what is allowed than what us not.  Much like your insurance company doesn’t state in your home owners policy you are not permitted to have bonfires in your basement.  Some ELUAs such the one for Windows 7 mentions; “The single primary user of the licensed computer may access a session from any other device using Remote Desktop”, but does not state you can have multiple sessions.  It does however state you can have multiple users sharing a single session using NetMeeting or Remote Assistance, which means both users are sharing the same desktop and application, not separate sessions.  The intent with this is to assist an end user.

The modification is promoted as a patch, but a patch would be provided by Microsoft. This ‘patch’ was created by someone named DeepXW who on their own web page refers to it as “Crack termsrv.dll, remove the Concurrent Remote Desktop sessions limit”.

Most of the reputable sites explaining the hack also include a disclaimer explaining it is a violation.  I have posted some examples at the end of my ramblings . Sites such as Experts-Exchange have even banned posting the hack as they have confirmed it is a licensing violation.

We also need to consider if this hack were legal, you would also require buying RDP/RDS CALs (Client Access Licenses), and if Office were installed you would only be legit if you purchased volume licensing with one license for each user. The latter two are requirements on any multi-session Microsoft O/S.  The Office 2013 ELUA does clearly state that you cannot have multiple sessions: “Remote access. The user that primarily uses the licensed computer is the “primary user.” The primary user may access and use the software installed on the licensed device remotely from any other device, as long as the software installed on the licensed device is not being used non-remotely by another user simultaneously.”  This same issue applies to third party software which in many cases has the same limitations.

Granted the hack does work, with some occasional Winsock issues, and though the chances of being caught are minimal, if discovered in a Microsoft audit, which does happen, the penalties are stiff.  I strongly encourage folk to approach this in a more secure, manageable, and legitimate way by using a Microsoft Remote Desktop Services Server (formerly called Terminal server).

Sample comments from various sites outlining the hack:

However, be warned. Before you begin, I need to warn you that patching the file and allowing more than one concurrent Remote Desktop session will violate a few lines in the Windows XP EULA. Proceed with caution and at your own risk. I shall not be liable for any damage caused to you, your computer, your data or your dog/cat because of this.  From <http://www.petri.co.il/multiple-remote-desktop-sessions-on-windows-xp-sp3.htm>

Desktop, which basically only allows the single primary user of the licensed computer to access a session of the computer. And that essentially tells us that the trick we revealed to enable multiple concurrent user in remote desktop in Windows 7 isn’t a legally licensed, despite that it’s really a good useful hack.  From <http://www.nextofwindows.com/how-many-concurrent-connections-allowed-to-access-a-windows-7-computer/

I think you find it is a license violation, as win 7 is single user at time OS.
As with all version of windows you need a license for all current users.
If you “hack it” you have violated the TOS and have voided the windows license.  From <http://social.technet.microsoft.com/Forums/windows/en-US/41e9e500-714a-443b-bff2-55f0d500d3d1/concurrent-sessions-remote-desktop-in-windows-7>

A quick note: enabling multiple concurrent RDP users may be against the Windows 7 End User Licensing Agreement (EULA). Please be sure to check the EULA beforehand and know that we do not recommend making these changes in cases where they may violate the EULAFrom <http://www.optimusbi.com/2012/12/05/enable-concurrent-rdp-connections-windows/>

Regardless of what solution you come up with, concurrent desktop access (if you are not sharing a single session) is in violation of the desktop Windows EULA.   From <http://arstechnica.com/civis/viewtopic.php?f=15&t=1190558

Windows 8 connect to VPN before logon

Last year I did an article entitled “Connect to a Windows VPN at logon”.  Rather than duplicate, please refer to that article for details, but It has been pointed out the method outlined is not available in Windows 8.  Actually it is but Win 8 by default alters the standard domain logon that was present since Win NT of pressing “Ctrl+Alt+Del”.  Restore that and you will again have the option to connect to a VPN prior to logon so you authenticate to the domain, and have group policy and logon scripts applied.

To re-enable “Ctrl+Alt+Del” either open the Local Security Policy under Control Panel, Administrative Tools, or open the local Group Policy editor by entering in the “Run” box gpedit.msc.  The location of the policy is in pretty much the same location in both, and setting in one will update the other.

  • In the Local Security Policy editor (control panel) it is located under; Security Settings | Local Policies | Security Options | Interactive logon: Do not require CTRL+ALT+DEL
  • In the local Group Policy editor (gpedit.msc) it is located under; Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Interactive logon: Do not require CTRL+ALT+DEL

The default state of the policy in Win 8 is “Not Defined” which on a domain joined computer effectively results in enabled.  You need to set the policy to disabled which will force the use of “Ctrl+Alt+Del”.   After doing so, I recommend running from an elevated command prompt  gpupdate /force, though it should not be necessary when editing the local policy.  On that note; you can enforce the use of “Ctrl+Alt+Del” domain wide by creating a GPO on your Domain Controller and editing the same policy.

image

Once you do so, and log off, you will see the familiar “Press Ctrl+Alt+Delete to sign in” message in the top left corner of the logon screen.

image

After pressing “Ctrl+Alt+Del” there will be a small network icon in the lower left corner

VPNCapture2

Click on the network icon and you will be presented with any VPN connection created on that computer.  Note these VPN connections must have been created using the “Allow other people to use this connection” option.  This discussion also applies only to domain joined computers.

image

image

Enter you domain credentials, the VPN will connect, authentication to the domain will be processed, and group polices and logon scripts, including your mapped drives, will be pushed to the client.

 

UPDATE:  Should the PC not be domain joined and you wish to automate the VPN connection, please see: https://blog.lan-tech.ca/2013/06/08/rasdial-automate-vpn-connections/

How to join a Windows Domain using a VPN

There may be occasions where you need to join an off-site computer to an existing domain at a remote office.  Most often this would be in a situation such as a satellite office which is part of a larger corporate network and there is a site-to-site VPN in place.  Though a site-to-site VPN is by far the easiest way to join, it can be done using a Windows VPN client, which will be discussed further on in this article.  The primary problem encountered when joining the domain is DNS, but this is easily dealt with.

Joining the domain using a site-to-site VPN

  • Only 1 network adapter can be enabled on the PC joining the domain, and preferably a wired connection.  If any others exist such as a wireless card, disable until domain joined.  On occasion Bluetooth adapters will also conflict, so I recommend disabling them as well.
  • Configure the connecting PC’s network adapter either statically or through DHCP to point ONLY to the domain controller at the corporate office for DNS.  Do not add an alternate external DNS server such as an ISP or router as these will often respond first and name resolution will fail.
  • In the NIC configuration, under Internet Protocol Version 4 (TCP/IPv4) properties, click advanced, and under the DNS tab insert the corporate internal DNS suffix, such as CompanyDomain.local in the box entitled “DNS suffix for this connection”
  • image
  • Then join the domain using the traditional method of Computer (formerly My Computer) | Properties | Change Settings |  Change | enter the internal domain name | click OK | and you should be prompted for credentials for an account authorized to do so, a Domain Admin account.  If the Domain Controller is a version of Small Business Server the SBS option to use  http://SBSname/connectcomputer  or http://connect most often will not work.  (more detail and screen shots for the joining the domain process can be found below in the using a VPN client section).
  • If you wish to simultaneously import an existing local user profile, you can use ProfWiz as outlined in the following link which will both join the domain and move the profile. Though the article references SBS, it can be used with any Windows Server Version.  https://blog.lan-tech.ca/2011/05/19/sbs-and-profwiz/

Joining the domain using a Windows VPN client

Joining a domain using a VPN client is a little more involved, but not complicated. This method may work with other VPN clients, so long as they have the option to connect to the VPN before logon, but this explanation uses only the Windows built-in VPN client.  Without the ability to connect before logon, there is very little advantage even if you can join the domain, as you would not actually be authenticating to the domain.  I will assume the server end, RRAS, is configured and working for VPN client connections.

  • Log on to the PC you wish to join the domain with a local administrator account
  • Only 1 network adapter can be enabled on the PC joining the domain, and preferably a wired connection.  If any others exist such as a wireless card, disable until domain joined.  On occasion Bluetooth adapters will also conflict, so I recommend disabling them as well.
  • Establish a VPN connection.  If not familiar with doing so:
    • From the network and sharing center choose “Set up a new connection or Network”
    • Select “Connect to a workplace”
    • Choose “Use my Internet connection (VPN)”
    • Enter the public facing FQDN of the corporate VPN server such as VPNserver.MyDomain.com and enter a friendly name for the connection, anything you like.  It is also very important to check the box “Allow other people to use this connection” as you will soon have a domain account which will require access to this VPN connection.
    • image
    • Enter a User name, which ideally is the user that will be using the connection once joined to the domain, but can be any user name that is authorized to connect to the corporate network via VPN.  If you use a name other than the ultimate user of the PC they will simply have to change the user name during in the connection wizard, the first time they try to connect.  Enter the password and choose connect.  For security reasons I don’t recommend checking “Remember this password”.
    • image
    • If prompted for a network type after connecting, choose “Work Network”.

  image

  • Presumably you were able to establish a connection.  However while connected if you did an NSlookup from a command line for the server name, you will see it fails. Try an NSlookup for the FQDN of the server, and it will succeed.  Thus, we need to configure DNS for the VPN clientbefore proceeding.
    • image
    • Disconnect the VPN client
    • In the network connections window right click on the VPN/PPP connection and choose properties | Networking tab | highlight Internet Protocol Version 4 (TCP/IPv4) and choose properties | Advanced | DNS tab | and enter the IP of the corporate DNS server under DNS server addresses and the internal domain suffix such as MyDomain.local in the “DNS suffix for this connection box.  If admins need to connect to the remote client PC for administration by name check the box “register this connection’s address in DNS” but I would discourage this as the IP can change frequently and cause issues.  Also on the “IP Settings” tab leave the option “Use default gateway on remote network” checked, at least for now, so that all traffic is forced to the corporate network while the VPN is connected.
    • image
  • Now you can try joining the domain
    • Connect the VPN client
    • Right click on “Computer” (formerly My Computer) and choose properties.
    • In the resulting window select “Change Settings”
    • image
    • Slect “Change” again
    • image
    • Enter the corporate internal Domain name, such as MyDomain.local in the Domain box and click OK
    • image
    • You will be prompted for a domain account with privileges to join a PC to the domain, a Domain Admin.  Enter it and the password and you should receive a message advising you have been joined to the domain.  Be patient it takes a little longer as this is a slow link compared to the LAN.
    • image
    • You now need to reboot the connecting PC.
  • In order to authenticate to the corporate network at logon and work as if on the corporate LAN, you need to connect the VPN before logging on to the PC.  When the PC reboots press Ctrl+Alt+Delete as you normally would, and then choose  “Switch User”
    • image
    • You will then be presented with a new option, a little blue icon in the lower right corner.
    • image
    • Clicking this allows you to choose to connect to the corporate network, by using the VPN.  After entering your credentials you will see the familiar VPN connection automatically start, it will connect, and you will be authenticated to the domain.
    • image
    • Logon is a little slower of course due to the slow link, and the first time you connect it will have to set up the local domain profile.  If you make use of redirected my documents, offline files, or have a lot of group policies logon can take a very long time while they apply and sync.  If logon is too slow, you may want to review options available to the remote user.  You will note that if you now try nslookup <servername> works as it should.

Note:  If connecting from Windows 8, please see the following updated article:  https://blog.lan-tech.ca/2013/03/02/windows-8-connect-to-vpn-before-logon/

 

Depending on the performance of the VPN connection, it is sometimes necessary for the network administrator to “tweak” a few Group Policies for slow network detection. The following policies can assist with this:

Server 2008 / 2008 R2 / SBS 2008 / SBS 2011:
  • Computer Configuration | Policies | Administrative Templates | System | Group Policy | Group Policy slow link detection
  • Computer Configuration | Policies | Administrative Templates | System | Scripts | Run logon scripts synchronously
  • Computer Configuration | Policies | Administrative Templates | Network | Offline Files | Configure slow-link mode
  • Computer Configuration | Policies | Administrative Templates | Network | Offline Files | Configure slow link speed
Server 2003 / SBS 2003 / SBS 2003 R2:
  • Computer Configuration | Administrative Templates | System | Logon | Always wait for the network at computer startup and login
  • Computer Configuration | Administrative Templates | System | Group Policy | Group Policy slow link detection
  • Computer Configuration | Administrative Templates | System | Scripts | Run logon scripts synchronously
  • Computer Configuration | Administrative Templates | Network | Offline Files | Configure slow-link mode
  • Computer Configuration | Administrative Templates | Network | Offline Files | Configure slow link speed

 

Toast For Our Tables

Remote PC firewall on or off ?

I was asked; “how can I tell from a command line if the firewall is enabled on a PC on our network, using a command line?”

Netsh is a very powerful tool for querying and setting the status of most anything network related. There are both the ‘netsh firewall’ and ‘netsh advfirewall’ options depending if XP, or Vista and newer.  I will deal with the advanced firewall as it is commonly used with Vista and Win 7 these days. The following command will return the available options:

C:\>netsh advfirewall show

The following commands are available:

Commands in this context:
show allprofiles – Displays properties for all profiles.
show currentprofile – Displays properties for the active profile.
show domainprofile – Displays properties for the domain properties.
show global    – Displays the global properties.
show privateprofile – Displays properties for the private profile.
show publicprofile – Displays properties for the public profile.
show store     – Displays the policy store for the current interactive session.

As you are aware the Advanced firewall can be set differently for domain, home, or public networks.  We are concerned with how it is set now, while on our network so we will use the show currentprofile option.  The result returns numerous details. By piping the results to the find command we can limit the output and simply determine if the Windows firewall is on or off  ( note: /I ignores case of the text in quotes):

C:\>netsh advfirewall show currentprofile |find “State” /I
State                                 OFF

Chances are you will not want to run to the machine to check so you can make use of Sysinternals/Microsoft’s PSexec to run netsh, or any command, on a remote machine.  You will need to run this with admin privileges for the remote machine. Therefore it is generally done from the server using a domain admin account.

C:\PSTools>psexec \\PC1 netsh advfirewall show currentprofile |find “state” /I

PsExec v1.98 – Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals – http://www.sysinternals.com

Starting netsh on PC1…ice on PC1…
State                                 OFF
(the output will often end with the following when run remotely: netsh exited on PC1 with error code 0.)

PSexec can be downloaded for free from: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Connect to Windows VPN at Logon

The internet is littered with questions about VPN connection and authentication issues as a result of using cached credentials.

  • How can I automatically connect my Windows VPN at start up?
  • Why do I have to re-enter my user credentials when connecting my corporate VPN?
  • How do I get Group Policy to apply to VPN connected users?
  • How do I use my work domain user account when I work from home using a VPN?
  • Why won’t my logon script run when connecting by VPN?

You can connect from any PC using a VPN, but in most cases you do so after having logged onto the PC first. If this is a “domain joined” corporate PC, when you logon without the domain controller present, you are not authenticating to the domain but rather using the credentials cached on the local computer from a previous logon.  As a result Group Policy cannot be updated, logon scripts are not applied, and most often you have to re-enter your user credentials when you do choose to connect to the office via VPN.

It is possible to connect to the VPN at logon resulting in an experience similar to that of the office, except of course for the reduced file transfer speed,  However, there are few conditions that must be met to do so:

  1. This applies only to the Windows VPN client. Newer Cisco VPN clients and a few others do offer methods to connect the VPN before logon, but they use different processes.
  2. The computer must be a member of the domain, and therefore Pro, Ultimate, or Enterprise versions of the operating system.  At logon you will be providing domain credentials which are automatically passed to the local logon, thus they must be the same.  Using the same username and password is not enough as logon credentials include domain or computer names.  Domain\JDoe is not the same as LocalPCname\JDoe.  If the computer is not already a member of the domain, it is possible to join a remote domain using the VPN connection.  To do so please see:  https://blog.lan-tech.ca/2012/07/25/how-to-join-a-windows-domain-using-a-vpn/
  3. Should the PC not be domain joined and you wish to automate the VPN connection, after logon, please see: https://blog.lan-tech.ca/2013/06/08/rasdial-automate-vpn-connections/
  4. When you create the VPN connection you must check the box “allow other people to use this connection”.

image

Having met these conditions, at logon there is now an option to connect using the VPN during logon.

Windows Vista and Windows 7:

At logon select “Switch User” and a new blue icon will appear in the lower right next to the familiar red Shut Down icon.

image

Clicking the icon will allow you to use the VPN connection, and simultaneously connect and authenticate to the corporate domain, and log on to your local PC

image

Windows XP:

At logon after pressing ctrl+alt+del, if you click the “Options” button there will new be a check box “Logon using Dial-up connection” which will use the VPN connection, and simultaneously connect and authenticate to the corporate domain, and log on to your local PC

image

Windows 8:

Please see the more recent post to enable on a Win 8 PC

Slow Links:

Depending on the performance of the VPN connection, it is sometimes necessary for the network administrator to “tweak” a few Group Policies for slow network detection.  The following policies can assist with this:

Server 2008 / 2008 R2 / SBS 2008 / SBS 2011:

  • Computer Configuration | Policies | Administrative Templates | System | Group Policy | Group Policy slow link detection
  • Computer Configuration | Policies | Administrative Templates | System | Scripts | Run logon scripts synchronously
  • Computer Configuration | Policies | Administrative Templates | Network | Offline Files | Configure slow-link mode
  • Computer Configuration | Policies | Administrative Templates | Network | Offline Files | Configure slow link speed

Server 2003 / SBS 2003 / SBS 2003 R2:

  • Computer Configuration | Administrative Templates | System | Logon | Always wait for the network at computer startup and login
  • Computer Configuration | Administrative Templates | System | Group Policy | Group Policy slow link detection
  • Computer Configuration | Administrative Templates | System | Scripts | Run logon scripts synchronously
  • Computer Configuration | Administrative Templates | Network | Offline Files | Configure slow-link mode
  • Computer Configuration | Administrative Templates | Network | Offline Files | Configure slow link speed

Client Deployment:

Network administrators may also want to considered creating a deployable VPN client for consistency, security, and with a company logo.  An earlier post outlines how to do so in detail:

https://blog.lan-tech.ca/2012/01/30/windows-vpn-client-deployment/

Configuring Hyper-V Core

There are already dozens of articles relating to configuring Microsoft’s Hyper-V Server 2008 R2 (the free core version), however a colleague’s intimidation of command line server management inspired me to post my notes to ease his mind and perhaps those of a few readers as well.  Yes, it is a command line only version of server 2008 R2, with only a 15 line/option GUI to assist with the most basic configurations……..

image

Yet, after some minor configuration and enabling some basic services, you can manage the server in a very similar way you would manage others servers with; Hyper-V Manager, administrative tools, remote access, a file explorer, and even a web browser.

It is worth noting that there are definite advantages to using this version of Hyper-V.  It is free, it supports more than 32GB of RAM (server 2008 R2 standard does not, you need Enterprise or Datacenter editions), smaller footprint, and a somewhat limited attack surface.

Notes:

  • I am assuming Hyper-V core is successfully installed and you are at the point of configuring, if not the following links may help you get to this point Test Hyper-V compatibility, Step-by-Step Guide to Getting Started with Hyper-V
  • The assumption in this configuration is the Domain Controller and DNS server will be a virtual machine on the Hyper-V host. As a result it is recommended the Hyper-V host is not joined to the domain as no domain logon server will be available until after the guest VM has been started.
  • “Management PC” refers to the PC, or server, from which you wish to manage the Hyper-V host
  • All command line entries below, on both server and management PC, must be done from an elevated command prompt. On the server the default is elevated, which is confirmed by the “Administrator” on command window title bar

Server Configurations (Hyper-V host):

Run native Hyper-V GUI configuration tool:

  • The configuration tool (as in image above, should automatically start at logon but if not, from a command line, enter sconfig
  • Item #1: Leave as a workgroup
  • Item #2: Enter the computer name
  • Item #8: Configure the network: Use a static IP.  I recommend at least primary server be an internal DNS server, secondary an ISP. (Keep in mind on a domain joined server/PC you should not combine internal and public DNS servers, but this is not domain joined).  Best practices suggests 2 NIC’s should be enabled, one for management and the other for use by VM’s, though this is not necessary.
  • Item #9: Set date and time
  • Item #5: Set Windows update settings auto or manual.
  • Item #6: Download and install all updates, reboot as necessary
  • Item #3: Add any local admin accounts. I recommend adding new account with a name matching the login account of the remote management PC.  The names must match for some services to work.
  • Item #4: Configure remote management by enabling sub-options 1 to 3
  • Item #7: Enable remote desktop access (note this is still command line only)
  • Item #15 Exit to a command line

DNS:

As stated the Hyper-V machine is not a member of the domain, therefore it is recommended the following additions be made to assist with name resolution

Use the Hosts file to allow the Hyper-V host to resolve the name of the management PC.  From an elevated command prompt , open the Hosts file using Notepad by entering: notepad c:\Windows\System32\drivers\etc\hosts .  Add a record in the Hosts file for your management PC/s using

IP <tab> Pc’s DNS name <tab> # a note (optional) <enter>
eg: 192.168.123.123     PCname.MyDomain.local    # management PC

(Note: it is very important hit return, after every entry including the last line, and then save. For more information about Hosts and Lmhosts files, and their syntax see: https://blog.lan-tech.ca/2012/04/26/hosts-and-lmhosts-files/

Add the domain suffix to the domain search list within the registry to further assist with DNS name resolution.  Start the registry editor using regedit and locate the following registry key:

     HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\SearchList

Then add your domain suffix such as mydomain.local (separate multiple suffixes, if needed, with commas)

Permissions:

To configure additional permissions on the Hyper-V host download Hvremote.wsf from:   http://archive.msdn.microsoft.com/HVRemote  to a USB drive or CD.  Then from a command line copy HVremote to local directory such as Temp folder.  DOS commands are as follows (assume HVremote is on a USB drive labeled D:

cd\
md Temp
copy D:\FolderName\hvremote.wsf  C:\Temp\hvremote.wsf

Run the following commands from the directory where hvremote is located to grant Hyper-V administrators the necessary permissions to do so.  This asdds the admin to the “Distributed COM User’s group”. Again from an elevated command prompt, run the following command using the user you created under Item #3 above in the initial configuration GUI.

     Cscript hvremote.wsf /add:user

If this is the first time hvremote has been used to add a user a reboot may be required

Firewall:

The necessary firewall exceptions should have been enabled by Item #’s 3 & 7 above.  You may also want to be able to ping (IPv4) the server for testing. To do so from a command line enter:

netsh firewall set icmpsetting 8

Or use the new command for “Windows Firewall with advanced Security”

     netsh advfirewall firewall add rule name=”ICMP Allow incoming V4 echo request” protocol=icmpv4:8,any dir=in action=allow

(Note: if cutting and pasting the above command, you will have to substitute the quotation marks using your keyboard.  This site’s/font’s quotation marks are not standard ascii characters)

For additional firewall information relating to pings see:  http://dpotter.net/technical/2010/02/enable-ping-on-windows-server-2008-2/


Management PC Configurations:

DNS:

If the PC is a member of a domain, you can add a Host (A) record to the DNS management console for the Hyper-V host, or you can make an entry in the management PC’s Hosts file similar to the instructions for the server. This will ‘point’ this to the server such as:

IP <tab> Server’s DNS name <tab> # a note (optional) <enter>
eg: 192.168.123.123     HVServerName.MyDomain.local     # Hyper-V host

Permissions:

As on the Hyper-V host, download HVremote from http://archive.msdn.microsoft.com/HVRemote  or copy from your USB Key to a local directory as below:

     cd\
md Temp
copy D:\FolderName\hvremote.wsf C:\Temp\hvremote.wsf

Using an elevated command prompt run the following commands from the directory where HVremote is located.  Where the Hyper-v host is not part of the domain you must enable anonymous DCOM access using:

     Cscript hvremote.wsf /mode:client /anondcom:grant

This one command must be run from an non-elevated command line:

Cmdkey /add:ServerComputerName /user:ServerComputerName\UserName /pass:UserPassword

Firewall:

There are 4 Hyper-V Management Client firewall exceptions that need to be enabled.  Running the following command, from an elevated command prompt, will do so:

     Cscript hvremote.wsf /mode:client /FirewallHyperVClient:Enable

You also need allow rules for MMC exceptions (management consoles) which can be applied with:

    Cscript hvremote.wsf /mode:client /mmc:enable

If you have other 3rd party firewall software installed, you need to manually configure it with the same exceptions.

If you wish to use the Disk Management component of the Computer Management MMC for the remote host, you need to enable the inbound “Remote Volume Management – Virtual Disk Service Loader (RPC)” exception with:

     netsh advfirewall firewall set rule name=”Remote Volume Management – Virtual Disk Service Loader (RPC)” new enable=yes

You also have to set the “Virtual Disk service” on the Hyper-V server to Automatic and start it.

sc config vds start= auto
sc start vds
    (not needed if rebooting – will automatically start)

Reboot:

To apply all changes a reboot of the PC is recommended.

Testing connectivity:

When complete test and review the output using the commands below.  For details and troubleshooting download the documentation for HVRemote from:  http://archive.msdn.microsoft.com/HVRemote

From the server:

     Cscript hvremote /mode:server /show /target:clientcomputername

From the client PC:

Cscript hvremote /mode:client /show /target:ServerComputerName


Remote Management Tools:

RSAT tools:

Download and install RSAT (Remote Server Administration Tools) on the management PC making sure you have the RSAT version compatible with that PC’s operating system. The link for Win7 SP1 is below.  With these tools you can now connect the Hyper-V host and manage it from a PC using  all those familiar tools like Computer Management, Disk Management, Windows Firewall with Advanced security, Task Sheduler, etc., and of course the most important; Hyper-V manager which will allow you to create and manage your VM’s the same as you would if you had the full GUI version of Server 2008 R2 as a host.

http://www.microsoft.com/download/en/details.aspx?id=7887

Remote Console (RDP):

You can access the Hyper-V console (still command line only) using a standard RDP connection. You can also install “Portable Apps” which you can then run from an RDP session.  See further down in this list of Remote management tools.

     Mstsc -v:<Hyper-V host name>

Portable Apps:

You can run standard “portable apps” on the console, or during a remote desktop session such as:

Windows Explorer Equivalent A43:

http://www.alterion.us/a43/index.html

Firefox Web Browser (for security reason web browsing from the host is not recommended):

http://portableapps.com/apps/internet/firefox_portable

Others:

http://www.portablefreeware.com/all.php

Powershell:

To remotely run PowerShell you will need Powershell 2. which is available from Windows updates. To install and enable please see the following article http://geekswithblogs.net/twickers/archive/2009/11/04/136013.aspx  With it from the Host console, or remotely, you can manage many services using scripts/cmdlets from:

http://pshyperv.codeplex.com/

Others:

http://www.portablefreeware.com/all.php

PSExec:

PSExec is a tool developed by Sysinternals, now Microsoft that allows you to run DOS commands on remote machines:

http://technet.microsoft.com/en-us/sysinternals/bb897553

Hyper-V Monitor Gadget:

A great desktop gadget for monitoring the status of your Hyper-V servers, status and perfomance, as well as the ability to start and stop.  Requires permissions and services as outlined earlier.

http://hypervmonitor.codeplex.com/


Additional Resources:

Configure Hyper-V Remote Management in seconds

http://blogs.technet.com/b/jhoward/archive/2008/11/14/configure-hyper-v-remote-management-in-seconds.aspx

Full HVRemote documentation and download:

http://archive.msdn.microsoft.com/HVRemote/Release/ProjectReleases.aspx?ReleaseId=3084

Install and Configure Hyper-V Tools for Remote Administration

http://technet.microsoft.com/en-us/library/cc794756(WS.10).aspx

How to use the “netsh advfirewall firewall” context

http://support.microsoft.com/kb/947709

How to Enable Remote Administration of Server Core via MMC using NETSH

http://blogs.technet.com/b/askds/archive/2008/06/05/how-to-enable-remote-administration-of-server-core-via-mmc-using-netsh.aspx

Drive Mapping Basics

We have all been mapping drives using various methods so long as we have had networked computers.  A recent discussion with a colleague revealed that many IT pros still use the same methods they used with NT4, during the last century. Though these methods still work as well today as they did 10 to15 years ago, if enlightened these folk might find some of the newer options using group policy and preferences easier to manage and apply, in a windows domain environment.  I am sure this article is a very basic review for most, so I have titled each so that you can quickly locate methods that may be of interest, or skip to using group policy near the end like any good “cliff hanger”.

1)  Manually:

The option still exists with Windows 7 to open windows Explorer, click on the menu bar, select “Map a network drive”, select the drive letter and path, and choose whether to reconnect at next logon.  This is hardly a reasonable way to deploy mapped drives to multiple users as it would require going desk to desk.  The other primary downside to this option is end users can override, delete, and add their own mappings which may conflict with mappings you are trying to push out from the server.  The latter to be addressed with the deployment methods #3 and on.

image

2)  From a command line:

Though probably even less practical, the option also exists to duplicate the above from a command line by simply using:

Net Use X: \\ServerName\ShareName /persistent:yes

3)  A batch file

The next step up would be to apply the Net Use commands using a batch file (also called script) which the user can apply by clicking on a desktop shortcut or by adding it to the start menu “StartUp” folder.  Though this method of applying the batch file is not at all practical, using a batch file is a reasonable option. Alternate methods to apply a batch file are discussed later, but I will take this opportunity to discuss the script itself and the syntax.  The script could be written using VBS or other languages, but for simplicity I will stick to DOS commands.  The script is written in a text editor like “notepad” and saved with a .bat (or .cmd) extension.  When saving, to be sure the .txt extension is not automatically added, place quotes around the file name such as “MyScript.bat” .

The basic line to apply the drive mapping is still the same:

Net Use  X:  \\ServerName\ShareName

However, as mentioned in #1 users have a tendency to occasionally create their own mappings, or you may want to make changes from time to time, so I like to start with a clean slate, delete all existing mappings, and make sure they will not automatically be recreated due to the “/persistent:yes” option.  To do so start the script as below, followed by the drive mappings. (Note: DOS commands are not case sensitive)

Net Use /persistent:no
Net Use * /delete
Net Use X: \\ServerName\ShareName1
Net Use Y: \\ServerName\ShareName2
Net Use Z: \\ServerName\ShareName3

It is also possible to add GoTo statements and Labels to filter a script.  For example you may want one script for multiple users on multiple devices, but the required mappings may vary for different users, on different servers or PC’s, or when users are members of different groups.  This is not a scripting lesson but to provide an example, in the following batch file the mappings will not be applied if run on a server named Server1, and User1 and User2 will have different drive mappings than other users.

If "%ComputerName%" == "Server1" GoTo END
Net Use /persistent:no
Net Use * /delete
If "%UserName%" == "User1" GoTo MAP1
If "%UserName%" == "User2" GoTo MAP2
Rem  apply default mappings to all others
Net Use X: \\ServerName\ShareName1
Net Use Y: \\ServerName\ShareName2
Net Use Z: \\ServerName\ShareName3
GoTo END
:MAP1
Net Use X: \\ServerName\ShareName1
GoTo END
:MAP2
Net Use Y: \\ServerName\ShareName2

The following sites will provide additional information regarding DOS commands and syntax, or using IfMember (for group membership filtering)  instead of If %UserName%

4)   Batch file, applied through the user’s profile

Continuing with using the batch file method; it would be more practical to apply it from the server, when the user logs on to their workstation than by installing on each machine.  The crudest method of doing so which has been around for more than 10 years, is to apply the script though the user’s profile in Active Directory Users and Computers on the server.  The default location to place the script is  C:\Windows\sysvol\sysvol\<your domain>\scripts.  This path is also a default share, \\ServerName\Netlogon  for which all domain users have read permissions.  The location can be change but if so permissions have to be considered and the path provided.  Why “re-invent the wheel”, use the default file path.  On server 2008 / 2008 R2 you must be an administrator and have “elevated privileges” to write to this file location. When opening the text editor (Notepad) right click on the application or shortcut and choose “run as administrator”.   Failing do to so will not allow the file to be saved.image

Once the batch file has been placed in the appropriate location, open the user’s profile in Active Directory, and in the box labeled “Logon Script” under the “Profile” tab, insert the name of the script.  It will be applied the next time this user logs on to a domain joined machine.  The only real disadvantage of this method is the name of the batch file has to be manually added to each user’s profile.

image

5) Batch file, applied using Group Policy

Now the 21st century methods:  Group policy is the ideal way of managing users and controlling their environment.  The possibilities are endless, but the focus is on mapping drives.  Again place the script in the default location mentioned above; C:\Windows\sysvol\sysvol\<your domain>\scripts heeding the notes about requiring elevated privileges.  Instead of applying through the user’s profile, which only affects one user, we can now apply to all members of an OU (Organizational Unit) through Group Policy.  This example will use an OU named Sales.  I will assume the users belonging to the Sales OU have already been added in active Directory.  The policy can be applied to an OU at any level, including the domain level if preferred, though it is a “User Policy” so I recommend applying to a User OU.

Open the Group Policy Administration Console under Administrative Tools, and locate the OU to which you wish to apply the Logon script. Right click on the OU and choose “Create a GPO in this domain, and link it here”. The following image shows the OU structure used on a Small Business Server.

image

Name the policy

image

Right click on the new policy and choose edit

image

Expand the tree to locate <your domain name> | User Configuration | Policies | Windows Settings | Scripts (Logon/Logoff) | in the right hand window right click on Logon and choose properties| click add, then enter the path or browse to your logon script.  Save by choosing OK, OK.

image

Group policy can take up to about 90 minutes to apply to workstations.  If you wish to force it to update form a command line run:  gpupdate /force  then log off and back on.  The drive mappings should be applied.

6) Using Group Policy Preferences

The latest method for applying drive mappings also uses Group Policy but does not require a script at all.  Server 2008 introduced Group Policy Preferences.  This method applies the mappings to a specified OU similar to the example above with the Sales OU, but uses a different feature or object within the Group Policy management console.  Again right click on the OU to which you wish to apply the mappings and choose “Create a GPO in this domain, and link it here”, name the policy, and select edit as in #5 above.  This time expand the tree to locate <your domain name> | User Configuration | Preferences | Windows Settings | Drive Maps.  Right click in the right hand window  and choose New | Mapped Drive

image

In the resulting window first choose Create or Replace.  Create seems to be the more common choice.  Replace does function more like the earlier script in that it deletes existing mappings and options, and completely re-creates the new drive mapping.  Next enter the share UNC path and select the drive letter. I prefer not to select reconnect, which is similar to opting for  /persistent:no  as explained in the earlier scripting section.  Then save the drive mapping by simply clicking OK.  For more information on Drive Map options see: http://technet.microsoft.com/en-us/library/cc770902.aspx

image

Once complete the new drive mappings will be displayed in Group Policy similar to the following image:

image

Remember as in #5 if you wish the Policy Changes to be applied immediately, you must run gpupdate /force on the workstations to be affected.

Group Policy Preferences is obviously the simplest method for creating and reviewing mapped drive configurations so chances are you only read the past 2 paragraphs, but hopefully it has be of some help to those looking at other methods or wanting a brief history lesson.

In the event you have problems applying Group Policies make sure you have waited 90+ minutes or run gpupdate /force, then if necessary you can run GPResult on the workstation, or on the server in Active Directory run the Group Policy Modeling Wizard .

Folder View Does not Refresh with Windows 7

Many people are reporting Windows 7 does is not refreshing the folder view when changes are made such as  adding or renaming a file or folder.  Hitting  the F5 key forces a refresh and immediately updates the view. There are dozens of suggestions scattered about the internet to change this setting or that setting which in many cases seems to resolve the problem.  After reviewing many of these the common solution seems to be to enable or disable any folder option under Computer | Organize | Folder and Search Options | View | any setting
such as  “Show hidden files, folders, and drives” and apply. You may need to log off and back on.

This is not a proper solution to the problem, nor does it explain why the problem occurs, but it does seem to resolve the problem in a large number of cases.

Tag Cloud