Showing posts with label server 2008. Show all posts
Showing posts with label server 2008. Show all posts

Sunday, 12 October 2014

Hyper-V Memory and Disk Allocations - Common Values

This post Is more of a reminder for myself opposed to something you will struggle to find elsewhere on the internet.

I work with Hyper-V a lot, bizarrely memory allocation is done in MB (who assigns less than a gig of RAM nowadays!) and disk space in GB (Fair enough, but I find myself creating 1tb+ VHD’s more often than less than a TB)


The table below lists some common conversions


MB to GB
Typical RAM allocations




MB
GB
1024
1
2048
2
4096
4
8192
8
12288
12
16384
16
32768
32
65536
64
 

GB to TB
Typical Disk allocations


GB
TB
1024
1
2048
2
3072
3
4096
4
5120
5
10240
10
15360
15
20480
20

Friday, 17 May 2013

ASP.NET fails to detect internet explorer 10 – The patches


We all know about the bug in .net 2 and .net4 browser definition files that prevents it from recognising certain browser types (namely IE10)

There are hotfixes available for this, but not via Microsoft update – you have to request them and the link is emailed to you.

This is an easy enough process and can be requested from:


.NET 2.0

http://support.microsoft.com/kb/2600100 - for Win7 SP1/Windows Server 2008 R2 SP1, Windows Vista/Server 2008, Windows XP/Server 2003

http://support.microsoft.com/kb/2608565 - for Win7/Windows Server 2008 R2 RTM
 

Or, if you run Server 2008 R2 SP1, here are the direct download links to save time:

 

.net 4


 

.net 2.0

Thursday, 27 October 2011

Getting service tag / bios info using powershell

Following on from my post “script to get service tag from dell device” I felt a bit “dirty” that I was using VB opposed to my new favourite thing in the world, powershell!

You can use a cmdlet “get-wmiobject” to pull all sorts of info from WMI, including the bios.

Therefore, this very simple one liner will return not only the service tag (or serial number for non dell devices), but bois version and a raft of other information.
Here is the command

Get-wmiobject win32_bios | fl *


The result will look something like this



If you have WinRM remoting configured, you can run this on a remote device by starting an interactive session, and then running the command

PS> enter-pssession servername
Server name: PS > get-wmiobject win32_bios | fl*

If you don’t have WinRM remoting enabled, run this command on the host to enable it.

PS > winrm quickconfig
WinRM already is set up to receive requests on this machine.
WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

Make these changes [y/n]? y

WinRM has been updated for remote management.

Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.



Sunday, 25 September 2011

Configuring default FTP logon domain

If you’re still stuck in the dark insecure age of the internet and using FTP, you may want users to login to your FTP site using their domain credentials.

By default, the FTP service will use the local user database on the server itself (unless you enter your username in the domain\username format), you can however configure IIS to use a domain by default.

Take caution in doing this though, if you’ve ever put an FTP server on the internet, take a look at the event logs, it will have a ton of brute force attacks on it within minutes.
By default FTP will be trying to authenticate locally, which is a much smaller attack surface (fewer users) as soon as you point it at your domain, it’s going to have a much larger attack surface (more users)

You need to make sure you don’t have any accounts such as “test” or users like “mary” with passwords of “password” or any dictionary word at all. You should also tie the FTP site down to the specific users that need access, so if an account does get compromised it can’t be used to put data in the FTP directory.
With the above in mind, use an elevated command prompt to run the following on the FTP server

adsutil set msftpsvc/DefaultLogonDomain "YourDomainName"
This will set the default logon domain for all FTP sites.

Friday, 13 May 2011

Using a PAC file to set proxy settings

There are many ways to configure proxy settings, via a GPO, via a build, or an application.

Proxy settings can cause issues for mobile users if they use their device away from the corporate LAN as the proxy server will not be reachable, this will render the internet browser unusable (unless of course Direct Access has been implemented)

There are many solutions to this problem, some common ones are:
1. Teach users to enable and disable proxy settings, This is not the most elegant solution, is likely to cause a fair amount of support calls, and also means proxy settings cannot be enforced.

2. Run a 3rd party app that users can click on and select proxy on or proxy off. Im not a fan of these types of applications that sit there and use up resources for no real reason.

3. Run a login script that sets the proxy setting if you are connected to the corporate LAN, and doesn’t if you are not. This is a long winded way of doing it, and is not 100% effective.

In my opinion, the most effective and efficient way of configuring proxy settings is to use a proxy auto config file (PAC)
A PAC file contains a JavaScript function "FindProxyForURL(url, host)". This function returns a string with one or more access method specifications. These specifications cause the user agent to use a particular proxy server or to connect directly

.
You configure your browser (works in all popular browsers) to use a script to configure proxy settings, this setting remains in place permantly. If the PAC file is placed on a web server accessible only within the corporate LAN, if the user is away from the LAN, the config file is not found, so therefore a proxy is not used.


When the user is within the LAN, the file is found, and proxy settings configured.
Some say that a login script can achieve this too, however the login script requires you to login to take effect.


Take a scenario where a user is in the office, closes the lid on his or her laptop, gets on the train then opens the lid, and connects via 3G.
If proxy settings were configured with a login script, the office proxy settings would still be present unless the user logged off and on again.
With a PAC method in place, the browser looks for the settings each time a page is requested, therefore it would fail to find the config file and connect directly.

Below is an example PAC file which can be modified to suit your needs. This could be further extended to look at the current IP of the client, and return a different proxy depending on where the client is. Eg if the client is within an IP range which is associated with the Paris office, the Paris proxy would be returned, or if the client is on a New York IP range, the New York proxy would be returned.


function FindProxyForURL(url, host)
 {
        
        // Direct connections to Hosts
         if (isPlainHostName(host) ||
         (host == "127.0.0.1") ||
         (host == "www.a-whole-domain.com") ||
         (shExpMatch(host, "*.a-entire-domain.com")) ||
         (shExpMatch(host, "10.20.30.*"))) {
           return "DIRECT"
         } else {
           return "PROXY proxy-server.domain.com:8080"
         }
 }



Within this file, access to the IP range 10.20.30.0 - 10.20.30.255 would be accessed directly (bypassing the proxy) aswell as the domain www.a-whole-domain.com. anything under the domain a-entire.domain.com would also bypass the proxy. everything else will be directed at the proxy server "proxy-server.domain.com" on port 8080.
Add additional sites to the proxy bypass list by copying an existing line and pasting it below.


Although a WPAD file could also offer similar functionality, in my experience a PAC file is much more flexible and will enable changes to take effect instantly.

Wednesday, 24 November 2010

Draining sessions from Remote Desktop Session Hosts / Terminal Servers

Maintaining terminal servers (or remote desktop session hosts as they are known now) in today’s world when users require access 24/7 is a challenge. Setting up an RDS farm, with a session broker will give you load balancing and fault tolerance. (I will write more about remote desktop server farms and session brokers in another article)
However notice I say “Fault Tolerance” this doesn’t mean that you can reboot session hosts without affecting users, it just means that your system will tolerate the failure of a session host. The users who were connected to the rebooted (or failed) session host will lose what they were working on and will have to reconnect.
The nature of a session broker is that it will try to distribute sessions evenly across all members of a farm; this is great, apart from when you want to reboot a session host without annoying your users.
There is no “live migration” of RDS sessions, once a user is on a host, that’s where they will stay until they log off. 
So how do you free up a session host to perform maintenance on it? Firstly you will need to plan your work in advance.
You can then use the “chglogon” command to begin “draining” sessions. There are many ways sessions can be drained, but it basically means the session host will stop accepting new connections. Eventually once your users have logged off, they will not be able to establish a new log onto the draining session host, so will establish a new connection on another session host, which mean eventually the session host you are draining will have no users logged into it.
There are four switches for the chglogon command:
/query – this will tell you what mode the session host is currently in
/enable – allows users to establish connections to the session host
/disable – doesn’t allow any new connections, or reconnections to an existing session.
/drain – doesn’t allow any new connections, but does allow users to reconnect to an existing session
/drainuntilrestart – does the same as /drain, but reverts to /enable after a reboot
NOTE: when using the /disable switch, this will prevent you reconnecting to the server via RDP. You need to ensure you have access to the console via another method other than RDP, or use the RD configuration utility from another RDS server to change the setting.
These commands could be utilised to help with automated updates. You could configure RDS1 to automatically install updates on a Saturday at 6PM, then create a scheduled task to run on a Friday at 6AM to run the chglogon /drainuntilrestart command.
This would hopefully mean by Saturday at 6PM there were no users left on RDS1 and it would be safe to automatically reboot after an update installation.
You could then use the same method with RDS2, RDS3 etc, but on different days to ensure 100% uptime of your RDS farm

Saturday, 11 September 2010

Using servermanagercmd to automate the installation of common roles and features in Windows Server 2008 (inc R2)

I try to configure as many of the settings on a server via group policy. This not only saves time, but provides 100% consistency and a very simple way of making system wide changes. An example of this is I will configure SNMP settings via group policy.



This is all well and good, but many of the configuration settings are dependent on a “role” or “feature” that may not be installed (such as SNMP) there is no built in way to automatically install roles and features using group policy like there is to configure services, or firewall rules.


This is where servermanagercmd comes in. as you will probably gather this is a command line interface to the server manager GUI.


If you’re deploying a large amount of servers and you want to avoid manually installing a common role or feature, this is very useful, and will save hundreds of clicks!


Within the Active Directory design of the network I support, each server role has its own OU, which is under a generic servers OU. In most cases there is a group policy applied to each OU, so settings specific to a server role can be set.


Because of this, I can use group policy preferences to create a registry entry under the runonce key which will run servermanagercmd with the appropriate switches to install what I want based on the role of the server.


The runonce key is located:


HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce


Any REG_SZ string that is created under this key will be run once on startup (hense the name)


I typically install three features on most of the servers I look after, Telnet Client, SNMP Services and Failover clustering, these are the commands I use:


Servermanagercmd –install –telnet-client


Servermanagercmd –install snmp-services –allsubfeatures


Servermanagercmd –install failover-clustering


You will notice on the SNMP string, I have added –allsubfeatures, this installs all the sub features under the feature or role heading you have specified.


More information on the servermanagercmd as well as switches for other roles and features can be found here:


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


Other switches of servermanagercmd worth noting are:


-query this will output the current roles and features installed


-remove this does the opposite of add