: 4582 | 108668 | 12353

Move mail controls to Policy for granular application 
Use this IdeaSpace to post ideas about Domino Server.

: 16
: 18
: 2
: Domino Server / Admin Tools
: mail, policy
: Bruce Stapley205 18 Apr 2008
:
: / Email
Restrictions such as quotas, attachments limits, and "user rules mail forwarding" -- all currently configured in Server Configuration documents, and therefore having a minimum granularity level of one server -- should be moved to Policy settings, since these are restrictions that apply to users, not to servers.



1) Bill Malchisky9254 (21 Apr 2008)
I understand the need for moving many tasks to policy and settings documents, but putting quotas there, for example, would ensure that the admin would need to create an explicit policy to set a user's mail quota or adjust it now--as it typically done in R5, ND6, and ND7 environments (and can be done this way in ND8).

Overall, this would create a lot of overhead for the admin, particularly with users that have existing explicit policies. So, you end up with scores of settings documents to adjust differently, the policy documents for people. So, business execs that need larger mail amounts, or are over quota and need quick relief because they have a major project to complete, but will delete documents shortly, would need a new setting document, have it applied, then have the user logout of Notes to get the Dyncfg to run and pull down the policy. So, it makes a decent situation now, worse is some regards.

Although I appreciate the concept of putting where feasible more settings and options into policies, sometimes the solution can be worse than the issue addressed. Also, at what point to do we stop putting things into policies? We can not have every setting in Domino there. Some things like attachment limits are handled by the router for efficiency. But in theory, I see the value of having OU based attachment limits...but have not been to a client site that required this...usually, their IT policy is company binding. Additionally, if too much is put into policies, you end-up with a performance detriment too, but that is another topic.
2) Bruce Stapley205 (22 Apr 2008)
Hmmm. I posted a clarification once, but I don't see it. Let's try this a second time...

@Bill:

I should have been more verbose in my original posting; let me clarify: I wasn't thinking of specifying quota *values* in policy, just the enforcement settings associated with quotas, which are currently stored in the Configuration document, with a granularity of one or more home servers. I am quite happy myself with the current arrangement where quota values are properties of a database.

Generally, though, my proposal to make such settings part of policy is a bit bigger than the words themselves; since policy is currently implemented by clients, and I am suggesting that policy control settings which are implemented by servers, I'm really suggesting that a new type of policy be implemented, where we can specify user-, group-, OU-, or Organization-specific restrictions that are implemented by servers.

My specific suggestion was regarding mail restrictions. Implementing these using granular policy might well require rewriting the router, which certainly would have, as you mentioned, an impact on performance, so that would definitely be a consideration for the admin to make. But I'll bet that, if implemented, IBM could come up with all kinds of other ways to implement server-side policy which didn't impact server performance.

Ok, clarification over.
3) Karen Hooper4022 (24 Apr 2008)
Are you suggesting that a server-side policy replace server configuration documents? I believe something has to be done with configuration documents as they can potentially override each other & the "Most specific to a server wins" can be very vague in a domino environment where there are lots of config docs. I like the idea of a visible hierarchy for server-side policies so that if I want to work out my mail settings for a domain I look into one place. Not sure though that I hijacked your idea for my frustration with configuration documents.










:
:




Welcome to IdeaJam


You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>






IdeaJam developed by

Elguji Software Logo