Using Domino Policies to reduce your Total Cost of Ownership! http://www-10.lotus.com/ldd/dpdblog.nsf/ en-us Fri, 9 Mar 2012 16:46:54 -0400 Fri, 9 Mar 2012 16:46:54 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policies-not-updating-maybe-its-your-location-document dynconfig Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policies-not-updating-maybe-its-your-location-document?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policies-not-updating-maybe-its-your-location-document
  The other day I came across a situation that I had never seen before.  A customer was complaining that their policies weren't updating.  So we turned on the usual debug for that situation, debug_dynconfig=1 and debug_policy=1.  Now the first step in the process that can result in a policy update is for the client to send it's Dynamic Configuration data (DynConfig for short) over to the server.  However, it only does that when connecting to the home mail server as defined in the current location document (as opposed to the one in the Person record.)  What was odd is that the debug never showed the DynConfig data being read from the local PNAB.  I could tell that because when debug_dynconfig is enabled, I would expect to see something like the following in the log:
               DynInfoRead:  length: 118
               DynInfoRead:  version: 8
               DynInfoRead:  entries: 7
               DynInfoRead:  flags: 0x221
               DynInfoRead:  unid[0]: OF00000000:00000000-ON852579AE:006DB32B
               DynInfoRead:  unid[1]: OF0713C81E:181A074A-ON06EDB68F:B0ACCDA2
               DynInfoRead:  unid[2]: OF00000000:00000000-ON00000000:00000000
               DynInfoRead:  unid[3]: OF00000000:00000000-ON00000000:00000000
               DynInfoRead:  unid[4]: OF7C896896:8DB06A8D-ON3032C851:794524EF
               DynInfoRead:  unid[5]: OF00000000:495FDDAF-ON852579AE:006DB32B
               DynInfoRead:  unid[6]: OF40181D5A:2830A69B-ON00F1D3C4:6E057E8E
                              unid[0]: Profile
                              unid[1]: Internet Address
                              unid[2]: Mail file
                              unid[3]: Catalog server
                              unid[4]: Client Record
                              unid[5]: Policy (OF portion for Server Config)
                              unid[6]: R8.x+ Policy

    Since I didn't see that, it made me think that either the DynInfo was unable to be read for some reason or that the client wasn't correctly determining when it was connecting to the home server.  In the end, the latter turn out to be the case.  The server listed as the home/mail server in the Location document being use was an abbreviated hierarchical name (where no CN, O, or OU is present) instead of a canonical hierarchical name (where they are).  Now, just looking at the Location in the UI won't show the problem since the fields are massaged by the form, you can see this below:

To really see if the issue exists you have to look at the location document from a view and examine the document properties.  Here you can see that the MailServer field is correct: "CN=Chicks/O=Iris".  If it had been "Chicks/Iris" that would have caused a problem.


Another way to detect that the issue exists is via the dynconfig debug information.  Here's an example of how a bad MailServer would show up:

            DynConfig> called for user CN=Mark Skurla/O=Iris home server Chicks/Iris cur loc Chicks NOTEID 0x8476 flags 0x40 cat server

You can see that the home server is abbreviated.  If it was correct it would appear thus:
            DynConfig> called for user CN=Mark Skurla/O=Iris home server CN=Chicks/O=Iris cur loc Chicks NOTEID 0x8476 flags 0x40 cat server

Now, editing the Home/mail server field in the Location document will correct the issue.  Therefore, you shouldn't normally be seeing this issue.  So if you are seeing this issue (and what we found with one customer), you probably have some automated method for setting this information, maybe using a 3rd party product.  If so either contact them or if their product allows you to change the behavior, do so yourself.

The SPR  MSKA8RYMRY has been created to have the client code put the server name in canonical form before using it as being another way to avoid this problem.

     Regards,
                        Mark
]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/policies-not-updating-maybe-its-your-location-document http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policies-not-updating-maybe-its-your-location-document?opendocument&comments Mon, 13 Feb 2012 15:41:32 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/having-an-issue-with-users-being-uploaded-to-id-vault-when-using-registration-api ID vault Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/having-an-issue-with-users-being-uploaded-to-id-vault-when-using-registration-api?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/having-an-issue-with-users-being-uploaded-to-id-vault-when-using-registration-api
  I came across an odd bug last week that I captured in an SPR MSKA8R8JWK.  I have a fix and will be submitting it soon.  But since there was a work around that could be used NOW, I thought I would post about it.

 The issue occurs when registering users via the Notes API.  Note: the issue does NOT occur when using the Domino Admin client to register users.  You have to: 1)  register a user using the API, 2)  specify an explicit policy for the user that contains a security policy, 3) and have ID vault enabled in that security setting document.  One would expect that after the user is registered, that the ID would have been uploaded to ID vault.  But it does not.  The user could switch to their own ID and this will force a upload.  But that doesn't help you if you were expecting the user to have the ID downloaded to their client during their first access.

  The way around this is to assign the user to a group in the registration policy (not the security one!):



  If you do this, the user WILL be uploaded to the ID vault immediately upon registration.  However, the one drawback will be that any user assigned to that registration policy will be added to whatever group was listed.  But you can just delete the group later after you've finished registering people.  Just make sure that you specify a temporary group instead of an existing one so that you don't pollute a real group!

  Regards,
                     Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/having-an-issue-with-users-being-uploaded-to-id-vault-when-using-registration-api http://www-10.lotus.com/ldd/dpdblog.nsf/dx/having-an-issue-with-users-being-uploaded-to-id-vault-when-using-registration-api?opendocument&comments Tue, 17 Jan 2012 09:25:37 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-regression-issue-with-8.53-pubnames.ntf Regression Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-regression-issue-with-8.53-pubnames.ntf?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-regression-issue-with-8.53-pubnames.ntf
       I want to make you aware of an 8.53 template regression that we've found and how to get past it.

       Due to a fix for an SPR in the 8.53 codestream, we found a regression that would affect customer using policies with pre-8.0 clients.  The effect of the regression is to have policy settings be in effect for pre-8.0 clients that should not be.  8.0 clients and later are not affected.

              The backout steps have been verified in-house and also used at the customer site that raised the issue initially.  The steps are simple and straightforward, if you have any questions please post a comment.
               
       Regards,
               Mark

Here are the instructions):

• Open pubnames.ntf in the Domino Designer
• Open the PolicyManagement script library
• Click on the ComputeHAItemList subroutine
• Find the following lines of code:

                         
'                                        Set itemToDelete = hPolicy.GetFirstItem(pRefItemName)                
'                                        If Not itemToDelete Is Nothing Then                                  
'                                                itemToDelete.SaveToDisk = False                                    
'                                        End If  
                                       

• Uncomment these lines of code (remove the ' character at the beginning of each line)
• Save the subroutine
• Exit the Domino Designer
• Replace the design of your names.nsf with this version of pubnames.ntf
• Edit and resave any Policy Settings documents that have the issue

]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/policy-regression-issue-with-8.53-pubnames.ntf http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-regression-issue-with-8.53-pubnames.ntf?opendocument&comments Wed, 12 May 2010 09:10:25 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/customer-question-smart-upgrade Customer Question Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/customer-question-smart-upgrade?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/customer-question-smart-upgrade
  As you might imagine, I get questions about policies from customers through various channels.  I want to use this blog to share some of the Q&A so that other customers can benefit from the answers.  I'll use the Tag: Customer Question for these kinds of things.  In this particular question, the answer showed how the new Dynamic (aka Group) policies help to solve the customer's problem.

The situation was that the customer was using Smart Upgrade to upgrade the user base to Notes 8.5.1.  They did so by using the Smart Upgrade settings on a Desktop settings form tied to an Explicit policy applied to a set of users.  Like many customers do when upgrading to a new release, they were doing a limited rollout to a few users first.  The problem is that the customer would like upgrade an even smaller set of users to Notes 8.5.1 FP2 while the pilot was ongoing.  If they changed the Desktop settings document to set the Smart Upgrade fields to Notes 8.5.1 FP2, then all the users would be upgraded to that release.  So how could they:
             1) keep the majority of users upgrading to Notes 8.5.1
             2) have a small set of users be upgraded to Notes 8.5.1 FP2
             3) leave the current explicit policies defined in the person documents alone.

The #3 item is key.  The customer could have created another explicit policy and apply it to those users who've already been upgraded to 8.5.1.  But that means that they would have to check the status of each user and modify their person document manually to the new policy.  And they'd have to make sure that they had all of the existing Desktop settings in the new Desktop settings document.  If they changed any other Desktop setting they would then have to change it in two places.

The solution was to use a new Dynamic policy.  In the Policy Assignment tab the people to get the new policy could be listed (or a group could be used if they were all in one group.)  Then the new Dynamic policy was pointed to use a new Desktop policy.   The new Desktop policy then specified 8.5.1 FP2 like so:


The use of the Enforce setting is key.  Since an Explicit policy trumps a Dynamic policy in precedence, the Deploy Version from the Explict policy would be normally be used.  But with the Enforce setting enabled, the Dynamic policy's value will be used for Smart Upgrade while leaving all of the other Desktop settings coming from the Explicit policy.  

Using the above method, policies can be layered to selectively change values for a set of users while leaving the rest of the users and the rest of the Desktop settings unaffected.  In this case, the Smart Upgrade settings were modified but the same thing could have been done for other values.  A powerful tool indeed!

  Regards,
                     Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/customer-question-smart-upgrade http://www-10.lotus.com/ldd/dpdblog.nsf/dx/customer-question-smart-upgrade?opendocument&comments Thu, 21 Jan 2010 09:05:06 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/setting-client-location-values-via-policy Administration Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/setting-client-location-values-via-policy?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/setting-client-location-values-via-policy
     People often don't know that they can set the value of their client's Location settings via policies.  To do so you must of the Desktop policy settings document.  It can be a little hard to find though, since there are so many tabs and settings in the Desktop policy.  The Custom Settings tab will be off the screen when you first open the settings document.  So use the arrow controls show below to navigate over to the Custom Settings tab:

     When you put the document in edit mode, you'll see the Edit List button:


     Pressing that will allow to enter a name|value pair for a setting, like CatalogServer below:


  Now there are two important things I want to point out here.  There isn't a drop down list of what fields are on the form.  So if you don't know what it is, the one way to figure it out is to open the Desktop policy settings form in Designer.  There you will be able to see what fields correspond to which settings.

  The second thing to be aware of is a very important point.  Any setting you apply via this method will affect ALL Location documents.   There is currently no way to specify that only a particular location gets a particular setting.  Therefore if you want your end user's to have different settings for different locations DO NOT use this method.  I've seen customers use this feature not knowing that it applies to all Locations and then they have trouble backing out.  

   So I hope that this post has shown you how to use this feature and also informed you of a behavior that you might not have known about.

    Regards,
                       Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/setting-client-location-values-via-policy http://www-10.lotus.com/ldd/dpdblog.nsf/dx/setting-client-location-values-via-policy?opendocument&comments Thu, 19 Nov 2009 08:46:20 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/keeping-your-policies-simple Administration Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/keeping-your-policies-simple?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/keeping-your-policies-simple
  Everyone once in a while I'll be reviewing some customer data for some issue.  I'll look over their Domino Directory and review their policies.  In doing so I've noticed some things that I'd like to share as Best Practices.  The main idea is the standard concept of Keep It Simple!

  Since a lot of customers are running pre-8.5 versions of Domino, they only can use Organizational and Explicit policies.  Dynamic group policies were available starting in 8.5.  So it's very common to have users using mostly organizational policies with a few explicit policies thrown in.  There are two common issues I've seen and they both involve having more settings documents than are needed.  

  The first issue is involving hierarchical organizational policies, i.e.  orgunit2/orgunit1/org.  Now let's say that a company wants to specify a Desktop policy.  What I've seen is a Desktop policy specified at each level:
             */org                                  -> Desktop Settings 1
            */orgunit1/org                  -> Desktop Settings 2
            */orgunit2/orgunit1/org -> Desktop Settings 3

   And what I've seen with the above is that each of the above Desktop Settings documents are exactly the same!  I think this is because people are comfortable with the idea of precedence.  Having the 'Desktop Settings 1' document for */org automatically applies those settings to orgunit1 and orgunit2. Desktop settings documents at those levels should only be used if they are different and should override the ones at the org level. The trap here is that now later on a change could be made at the org or orgunit1 level and it won't be seen because the orgunit2 value will override it.  So the Best Practice is to only create the minimum number of settings documents.  This makes administration simpler and prevents confusion due to the masking of values due to precedence.  The desired configuration would simply be:
             */org                                  -> Desktop Settings 1

  The second situation is similar to the first but involves multiple organizations.  So it would look like this:
             */org1                                -> Desktop Settings 1
            */orgunit1/org1                -> Desktop Settings 2
             */org2                                -> Desktop Settings 3
            */orgunit1/org2                -> Desktop Settings 4

   Now let's say that all of the Desktop settings are the same except for */orgunit1/org2.  How many settings documents would be needed?  Two!
             *                                           -> Desktop Settings 1
            */orgunit1/org2                -> Desktop Settings 2

   The general policy of * will apply to all of the organizations.  People often forget that they can do that and assume that */ is the top level policy, but it is not, * is.  So that one policy would cover what three settings documents were covering.  Thus only the one additional setting document would be needed for the one orgunit.  So the Best Practice is when using organizational policies use the broadest possible scope, which often will be *.
   
   I hope that this will help demystify policies a little bit!

   Regards,
                     Mark
]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/keeping-your-policies-simple http://www-10.lotus.com/ldd/dpdblog.nsf/dx/keeping-your-policies-simple?opendocument&comments Mon, 26 Oct 2009 13:56:07 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-assignment-tab-question Administration Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-assignment-tab-question?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-assignment-tab-question
   Sorry for the long delay in posting.  Focusing on the 8.5.1 end game took me down for a while, but now I'm back and I hope to be posting much more frequently now.

   To start I'll post an answer to a question that I received via e-mail.  It involved the use of the Policy Assignment tab of a dynamic policy.  The question was, "Can a value of */ be used in there?"  The answer is no.  Only group or individual names can be specified there.  Putting a */ in there will have no effect.  If you really want to use that, just use an organizational policy instead which does support that.

    Regards,
                         Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/policy-assignment-tab-question http://www-10.lotus.com/ldd/dpdblog.nsf/dx/policy-assignment-tab-question?opendocument&comments Mon, 21 Sep 2009 15:20:34 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/how-to-avoid-locking-out-the-clients Best Practice Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/how-to-avoid-locking-out-the-clients?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/how-to-avoid-locking-out-the-clients
  Today I want to share how to avoid a common situation that people can get themselves into that can frustrate the end users.  Administrators often want to lock down certain settings for their end users, either to prevent them from tripping themselves up, for performance reasons, or to enforce a corporate policy.  For example, maybe an administrator wants to lock down the IBM Lotus Instant Messaging server by setting a value in a Desktop settings document and using the How To Apply control set to "Set value and prevent changes."  Now the end user can't modify that value locally.  So far, so good.

  But want happens if the administrator goes and deletes the policy that uses the Desktop settings after it has been applied?  The value will still be locked down, so the user will be unable to change it.  And if the user complains about this when the administrator looks at the policies for the user, they won't see that setting locked down anymore.  So what is this?

  This happens because policies are applied using a push model.  What was last pushed down is what stays in effect.  If the policy is deleted, nothing is ever pushed down saying that the policy is gone.  Part of the reason for this is that keeping track of who has received which version of a policy and when would be onerous for a large number of people and policies.  So what is to be done here?

   The recommended Best Practice is that when you have used policies to push out settings to end users, if you are going to remove a policy and not replace it with another one, then you need to 'reset' the settings first.  'Reset' settings means to unlock all of the settings and set the values back to the default or an empty value.  Once that has been push down to end users, thus allowing them to change their settings locally again, one can now remove the policy.  How long this 'reset' policy should be present depends on how long it takes for all users of that policy to have logged into their home mail server.  When they do that, they will get the updated settings.  But if someone is out on vacation, they will not have logged in at all.  So a month is probably a reasonable amount of time to wait.  And if you miss someone?  You could always just assign them a new temporary policy with just the defaults and then have them connect to their mail server.

  Following the above strategy will allow you to control the settings you want and not leave your end users in a locked out state!

  Regards,
                    Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/how-to-avoid-locking-out-the-clients http://www-10.lotus.com/ldd/dpdblog.nsf/dx/how-to-avoid-locking-out-the-clients?opendocument&comments Tue, 15 Sep 2009 11:19:38 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/another-dynconfig-performance-issue-fixed-in-8.5.1 Dynconfig Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/another-dynconfig-performance-issue-fixed-in-8.5.1?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/another-dynconfig-performance-issue-fixed-in-8.5.1
    In my previous post I reported on an issue where the Dynconfig process on the client was running too frequently.  You can tell this when you see the following status message in your client's status line, ""Notes configuration settings have been refreshed".  Well, while fixing that bug I found another issue that also causes Dynconfig to run too frequently.  So while it's not purely a policy issue, since the effect is the same I thought I would share it with you all.

    The issue is captured in SPR RDER7QJHXR.  Dynconfig brings down information for different areas of the client.  In addition to policy information, it will bring down information relating to mail, roaming, your client version, and from your person document.  The issue was related to roaming.  A regression in the code dealing with the roaming information caused the client version information not to be calculated at all.  The caused the client and server to think that the client version information did not match.  And this would cause Dynconfig to run to try and synchronize that information.  But the next time the information would be compared, the check would still fail and Dynconfig would run again.  So if you replicated or checked for new mail every minute or two, Dynconfig would run every time.  The fix corrected the logic error so that the client information was now correctly being calculated and Dyconfig was no longer being triggered.  

    So these last two issues could cause two things: 1) Dyconfig to run too often and impact the client and 2) cause an increase of transactions on the server impacting the CPU there.  So moving your clients and servers to 8.5.1 when it becomes available will resolve these issues if you have been experiencing them.

    Regards,
                       Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/another-dynconfig-performance-issue-fixed-in-8.5.1 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/another-dynconfig-performance-issue-fixed-in-8.5.1?opendocument&comments Tue, 1 Sep 2009 08:28:27 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/performance-issue-fixed-in-8.5.1 Dynconfig Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/performance-issue-fixed-in-8.5.1?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/performance-issue-fixed-in-8.5.1
  One of the things that I mentioned when I created this blog was that I would post about fixes I make in this area.  The idea is to keep you informed of updates so that if you are seeing an issue in your environment, you will know that it has been fixed.  So this post is my first follow through on that commitment.

  Yesterday I submitted a fix for SPR MSKA7VCSV3.  The issue was a performance problem on the server.  This was caused by the Dynamic Configuration process (DynConfig) on client machines running way too frequently and trying to bring down policy information from the server.  This results in a lot of SV_INFO_GET_RQST and GET_POLICY_RQST transactions on the server impacting the CPU utilization.  On one machine in-house the increase in CPU usage was 30%.  The issue was due to problem with memory management so its occurance was random.  But when it did happen, it was nasty.  This problem would only be found in the 8.5 release and it is now fixed in 8.5.1.  So if you thought you were seeing this issue, you definitely be wanting to migrate to 8.5.1 when it is released.

   Regards,
                      Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/performance-issue-fixed-in-8.5.1 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/performance-issue-fixed-in-8.5.1?opendocument&comments Mon, 24 Aug 2009 09:08:14 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/08242009091150AMMSKHEQ.htm Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/08242009091150AMMSKHEQ.htm?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/08242009091150AMMSKHEQ.htm
Today I just wanted to continue my initial rollout of this new blog.  As I mentioned in my previous blog, you can follow me on Twitter as well.  Don't worry I won't flood you with updates!  But I will try to post when I fix SPRs/PMRs, write new wiki articles, and other things like that.  To find me on Twitter you can either follow the link on the right side of the blog page under Links->Follow me on Twitter!  or you can follow this URL DomPolicy on Twitter and bookmark it.

I also added a general link which will bring up all of the Wiki articles that are tagged as policy related.  So that will make it easy to see them all at a glance.  Then I've added individual links to the Wiki articles that I've created for easy access.  Over time, I'll also add other links that I think will be interesting to the community.

By doing the above I've tried to create a site for all things policy related.  I will to add to this going forward, if you have any suggestions let me know.

Regards,
                 Mark ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/08242009091150AMMSKHEQ.htm http://www-10.lotus.com/ldd/dpdblog.nsf/dx/08242009091150AMMSKHEQ.htm?opendocument&comments Wed, 12 Aug 2009 09:56:20 -0400 http://www-10.lotus.com/ldd/dpdblog.nsf/dx/welcome Mark Skurla http://www-10.lotus.com/ldd/dpdblog.nsf/dx/welcome?opendocument&comments http://www-10.lotus.com/ldd/dpdblog.nsf/dx/welcome
  My name is Mark Skurla and I am the developer responsible for the Policy feature area in Notes/Domino.  I took over the area about a year ago.  One thing that I've learned over that time is that there is a lot of confusion with respect to policies.  Using a single policy is straightforward, but when you go beyond that they seem a total mystery to some people.  Thus the title of this blog, "Domino Policies Demystified".  I intend to use this blog as part of a concerted effort to clear up the confusion with policies, to enable customers to use them more effectively, and also gather feedback on how to improve them going forward.
 
   This 'concerted effort' consists of this blog, my posts on Twitter under the ID DomPolicy, Wiki articles in the Domino Wiki, and of course responding to posts on various forums.  I'll use the Twitter account for short posts that primarily will notify you of more detailed info on this blog or the Wiki along with maybe some short thoughts from the daily life of a developer.  I'll post to this blog at a minimum of once a week.  I'll post short thoughts or questions on various aspects of policies, particularly as I come across them in my discussions with customers on calls or via SPR/PMR work.  I'll also post when I fix problems in the policy area so that if you're experiencing the same issue you'll know that the fix is coming.  Lastly, I'll still do Wiki's in the Domino Wiki area for longer articles that go into more detail than I would do in a simpler blog posting.  

  I hope that these efforts will demystify Domino policies and in turn allow you to use them to leverage the many features of Notes/Domino and also reduce your administration costs.  I look forward to working with you and I am open to your comments and suggestions.

   Best Regards,
                                Mark Skurla ]]> http://www-10.lotus.com/ldd/dpdblog.nsf/dxcomments/welcome http://www-10.lotus.com/ldd/dpdblog.nsf/dx/welcome?opendocument&comments