Posts tagged Windows Server 2003
How to fix two computers showing as one in WSUS
4
So this week I’ve been tinkering with our WSUS server, normally it just sits in the corner minding its own business apart from once a month or so I go in and approve the next batch of updates for our desktops. For our server we, until now have always handled updated manually however that increasingly started to bug me so now its time to fix it, or at least make it slightly more efficient!
My aim is to have it so that once a month I can approve all the updates for our desktops and then let them install as normal based on when the PC’s are turned on and off. For the servers what I’m aiming for is to be able to approve the updates in WSUS and then have them only download to each server, thus allowing me to determine when to install them and reboot each server, it still requires some time from me over a weekend but should be much easier to manage (we normally block the MS Malicious Software Check tool and having to decline the tool each month on each server is boring), plus my hope is that this will reduce the frequency of Windows Update trying to ignore me and not offer to install updates after downloading them, or just not even popping up to offer the updates in the first place.
Managing Remote Desktop Sessions
1
As anyone who uses Remote Desktop a lot will by now know all too well, managing all those connections can be a real pain, especially if you need to make a config change that would normally require you to edit each connection manually.
Thankfully Microsoft has realised how much of a nightmare is (and how much the existing MMC plugin sucks badly), and they have provided us with a *much* better solution that is really easy to use and allows for logical grouping of servers into groups (and subgroups).
Once setup you can set default RDP preferences at an application, group or server level which means you can change an option in one place and have it apply to all your connections.
You can find out a bit more about the tool over on the MSExchangeTeam blog or you can jump right in and get the download from Microsoft here.
Setting up Cacti SNMP Monitoring on a Windows 2003 Server
2So this week I’ve been taking a break from planning our Exchange 2010 migration and have been playing around with Cacti as currently we have very little data on things like network and server usage short of a couple of key websites being monitored by an external site to track uptime, but absolutely nothing to tell us if servers are being overloaded or that our internet connection is being saturated.
For those who haven’t heard of Cacti before, its an open-source PHP based frontend that can be used to graph pretty much any data source you can feed it with the most popular source being SNMP which pretty much any business class network enabled bit of electronics supports these days. Even if you only have quite a small network like ours, it can be very useful to actually visualise whats going on, and its a lot easier to show your boss a graph showing how your internet connection is maxed out and needs replacing/upgrading than any other way!
How to Restrict Access to Terminal Servers
1After finally completing my Group Policy re-write for Windows 7 this week I have gone back to working on the plans for our migration to Exchange 2010. Currently we do use an Exchange 2003 server but only a few users are on it and it is only there to provide compatibility for a couple of specialised programs that are on our Terminal Servers. With the move to Exchange for all users possibly the biggest change will be that now all users have a Windows user account potentially allowing them access to the Terminal Servers when they shouldn’t have any.
In order to do this you could make use of the builtin group called ‘Remote Desktop Users’ which aslong as your using Windows 2003 R2 should have been setup when you installed the Terminal Servers role and by default has permission to connect remotely to any Terminal Server.
It is also possible to customise which users and groups can connect remotely to a Terminal Server so you make your life easier and reuse existing groups to control access, or setup multiple groups if you wanted to limit certain users from connecting to particular Terminal Servers. To do this you can either edit the Local Security Policy on each Terminal Server or apply the changes via Group Policy, the option you are looking for to set this via Group Policy can be seen below (the Local Policy method is also very similar to this and should be easy enough to find):
Inside this you can add all the users and groups who should have remote access.
While this may seem like all that is needed and while all the users and groups specified can now logon to the Terminal Servers you apply this to you will likely also find that infact *any* user can still login to the Terminal Servers. To correct this we need to make one final change as by default anyone in the Users group can access the server due to the ‘Allow log on locally option’.
While you might be concerned about the warnings given in the ‘Explain this’ tab advising you to not remove users, if you read the relevant section on the link provided it explains that it is safe to do this aslong as you dont remove important users from the list and aslong as users who should have access are granted permission to do so elsewhere.
Hopefully if this has all worked you now have a Terminal Services environment where only those users explicitly allowed can gain access.


