monkeydust.net

I came across this interesting question over on technet last week:

Hi,

Is there a way to restrict Mailbox owner from sending internal and external mails?
Are there any restrictive permissions which can be set on the user object in AD which will deny the user from sending any mails from his mailbox. The user should be able to receive and read the mails from the mailbox.

I have tried the option to set the sending limit of the user to 1 KB however i need to know if we can achieve this using permissions.

Mahendra

At first glance you may think that this is tricky to implement and requires messing around with permissions or server settings but as long as you are using Exchange 2007 or Exchange 2010 it is easy to implement (and more importantly, easy to manage!), and it is a great way to introduce how to work with Transport Rules.

Continue reading “How to restrict a user from sending or receiving any emails” »

Just been reading this guide over at http://msexchangegeek.com and think that anyone who is planning an Exchange 2003 to Exchange 2010 migration should give it a read as it includes some additional steps to take that aren’t included in Microsoft’s Exchange Deployment Tool such as moving the OAB generation to the new server aswell as upgrading the address lists from LDAP filters to OPATH and upgrading Email Address Policies.

So 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!

Rather than re-write an existing guide, the easiest and quickest way to get Cacti running is to follow this guide written by a very helpful Cacti user over on the Cacti Forums. Below are a few additional tips that should help you avoid some of the problems I ran into when setting up Cacti on a Windows 2003 server.

1. Dont use PHP 5.3, stick with 5.2 as 5.3 doesn’t yet include the SNMP module and so wont work with Cacti.
2. Do install Cygwin, its only an optional step but for the little extra work needed it will make patching Cacti with updates a lot easier (bug fixes only get released as .patch files so having Cygwin installed allows you to run the patch command just like on linux).
3. Dont install Apache unless you plan on using it in place of IIS, if you already host sites using IIS then there is no need to install Apache at all.
4. If you are using IIS make sure you install FastCGI before you install PHP, FastCGI is the recommended way to run PHP as of 5.2, its as simple as running the installer so there is no reason not to use it.
5. When you reach the IIS instructions, if you are using FastCGI the skip to step 8, dont miss this out as step 8 and onwards talks you through setting the file permissions correctly and Cacti will not work properly without them!
6. When setting the permissions I had to always use the Advanced > Find option to select the IUSR_ user as it could not be found when typing in the name as normal.
7. If you are polling other Windows based machines then make sure you increase the SNMP timeout value when adding the device, for some reason Windows takes longer to respond to SNMP queries, setting it to 5000 works fine for me.
8. By default SNMP isn’t enabled in Windows, see this Knowledgebase Article for how to enable it.
9. Finally, if once SNMP is enabled on a machine and it still isnt sending any SNMP data despite you being positive that it is setup Ok, try removing the SNMP feature and re-installing it. I’ve had this happen on a couple of Windows 2003 boxes and after reinstalling the SNMP service it has started working.

After 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):

Enable the 'Allow log on through Remote Desktop Services' Option

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’.

Remove the Users group from 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.