Responsibilities of Problem Manager

Problem Manager:  Provides a single point of contact for one or more problems and is    responsible for ownership and coordination of actions of those problems to analyse for root cause, identify known error and coordinating actions to remove the error.

1.       Produces problem management reports and management information

2.        Identifies trends and potential problem sources (by reviewing incident and problem     analyses)

3.        Prevents the replication of problems across multiple systems

4.       Reviews the efficiency and effectiveness of the problem control process

5.        Coordinates meetings to resolve problems

6.       Maintains inventory of problems under analysis and their current Progress and status

7.        Follows up issues and progress with problem owners where necessary

8.       Identifies resources needed to resolve problems

9.       Assigns the problem owner

10.    Monitors the effectiveness of error control and makes recommendations for improvements

11.      Develops and maintains problem and error control systems

12.    Reviews the efficiency and effectiveness of proactive problem management activities

13.     Reviews incident data to analyze assigned problems

Investigates assigned problems through to resolution or error identification

14.    Coordinates actions of others as necessary to assist with analysis and resolution actions for problems and known errors

15.     Raises RFCs to clear errors

16.    Monitors progress on the resolution of known errors and advises Incident management staff on the best available work-around for incidents related to unresolved problems/known errors

17.   Assists with the handling of major incidents and identifying the root causes

Responsibilities of Problem Coordinator

 Problem Coordinator: Responsible for reviewing problem trends and proactively taking actions to identify problems and remove errors for a department or business unit 

1.       Developing and maintaining the problem control process

2.       Reviewing the efficiency and effectiveness of the problem control process

3.      Producing management information

4.      Allocating resources for the support effort

5.      Monitoring the effectiveness of error control and making recommendations for improving it

6.      Developing and maintaining problem and error control systems

7.      Reviewing the efficiency and effectiveness of proactive problem management activities

8.      Service Desk to indicate that the problem has been passed to problem management

9.      Problem management to log, monitor and track the progress of the problem

10.   Service Desk or technical staff or the problem manager/process owner to spot trends in incidents

11.    Problem management to action problems raised from incident management

12.    Problem management to progress unresolved incidents through the problem management process

13.   Problem management to assist with the handling of major incidents and identifying the root cause

14.   Technical staff to actively prevent the replication of problems across multiple systems

15.   Configuration management or change management specialists to be consulted

16.   Second line and third line support groups, including specialist support groups and external suppliers, to provide expertise

Roles and responsibilities of Change Coordinator

1.0             Change Coordinator: The primary role of the change coordinator is to coordinate the flow of documents surrounding any changes to an ongoing project or large system.

1.       Ensure documentation of the request must include the actual item to be changed, the business rational for the request, and the expected benefits and risks inherent with the request.

2.       Registers changes and applies the correct change model and change detail.

3.      Schedules changes according to the plan created previously.

4.      Creates the change tasks for building, testing, and implementing a change.

5.      Coordinates the assessment phase of the change and creates change planning based upon the assessment information.

6.      Verifies that the change passed the test criteria.

7.      Verifies that the change is implemented successfully in the production environment.

8.      After implementation, evaluates the change handling and closes the change.

9.      After or during a change implementation failure, activates the remediation plan to return the system to a pre-change state.

10.   Evaluate its risk: determined by impact and complexity.

11.    Evaluate its Priority: Determined by the Urgency and importance of the change.

12.    Business Assessment – How will the change benefit the customer?  Will SLAs be impacted?  Is the change within scope of the contract?

13.   Technical Assessment – Why do we need to do this change and what will happen if we don’t do the change?

14.   Ensure “Step-by-Step” Installation Instructions, Back out Plan, Back out duration, Customer Impact, Post Checks.

15.   Pre-implementation test results ,

16.   Detailed Instructions for support groups, Communications, documentation updates/locations, and contacts. Technical and business feasibility.

17.   Responsibility to ensure that all requests are approved by the appropriate person. By requiring approval from senior staff, all requests must be explained to a member of the management team, who may have a different perspective and see additional risks or benefits.

18.    Check the timing of the check; ensure this change is not clashed with other changes.

19.   Check the if the duration of the change is within the change window.

20.  Check if all the required approvers are added to change record and change is approved by all the relevant parties.

21.    If a change is rejected, the person rejecting the change should add a note specifying why the change was rejected. Notification should be made to the assignee/requester so that the situation can address quickly.

22.   Verify the change results.

23.   Check if change is implemented within the agreed upon window.

                                       Change Management Process Flowchart For Reference

ROLES & RESPONSIBILITIES for Change Manager

 
  

1.0             Change Manager: Provides a single point of contact and is responsible for coordinating all change functions within that organisation

1.       Receive, log and allocate a priority, in collaboration with the initiator, to all RFCs Reject any RFCs that are totally impractical

2.       Reviews all changes after the assessment and planning phase and forwards them the right Change Approver.

3.      Organizes Change Advisory Board meeting if necessary.

4.      Updates the change after approval is given.

5.      Periodically reviews changes in a Post Implementation Review and determines and executes follow-up actions.

6.      Coordinates all activities in case the Emergency Change Handling process is triggered.

7.      Circulate all RFCs to CAB members in advance of meetings to allow prior consideration

8.      Decide which people will come to which meetings, who get specific RFCs depending on the nature of the RFC, what is to be changed, and people's areas of expertise

9.      Convene urgent CAB or CAB/EC meetings for all urgent RFCs

10.   Represent organisation at all CAB and CAB/EC meetings

11.    After consideration of the advice given by the CAB or CAB/EC, authorize acceptable Changes

12.    Performs Stakeholder Management activities to identify Stakeholder concerns and issues with solutions being developed.

13.   Monitors stakeholder acceptance/rejection of solutions being developed.

14.   Crafts and controls key communications and messages about the implementation effort.

15.   Identifies opportunities to win acceptance of solutions being developed by those who are impacted.

16.   Identifies channels for communications and builds the overall communications plan.

17.   Develops a Resistance Management Plan to provide strategies for dealing with rejection or resistance to solutions being developed.

18.   Ensures appropriate levels of the organization are involved and demonstrating active commitment and leadership to the solutions being developed.

19.   Coaching senior management and other key personnel to help them “walk the talk” and demonstrate commitment to the ITSM solution.

20.  Identify the Forward Schedule of Changes (FSC) for changes

21.    Coordinate with all necessary parties to perform Change building, testing and implementation, in accordance with schedules

22.   Update the Change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve service quality

23.   Review all implemented Changes to ensure that they have met their objectives. Refer back any that have been backed out or have failed

24.  Review all outstanding ABC RFCs awaiting consideration or awaiting action

2              25. Analyses change records to determine any trends

26.  Close RFCs

27.   Produce regular and accurate management reports on changes

2.0        Change Management Process Flowchart For Reference

Considerations for moving or migrating ADRMS

Moving ADRMS is a challenging task which needs proper planning and understanding of the environment. You need to consider keeping back up of the environment i.e. ADRMS database has to be backed up before going for ADRMS upgrade or movement.

Hence first decide whether to upgrade the existing environment or migrate the set up

Upgrading involves the risk of upgrading the server from windows server 2008 to windows server 2008 R2 with the download package available from Microsoft.But migrating the set-up to new windows server 2008R2 would be more safe and feasible option which involves considerably more steps but it’s a reliable option.

Some of the points given on Microsoft TechNet article need to be considered carefully

•            If you are upgrading from any version of Rights Management Services (RMS) to AD RMS, do the following: Back up the RMS databases and store in a secure location.
•            If you are using centrally managed keys, you should have the password prior to beginning the upgrade.
•             AD RMS requires that the service account be a domain user account. If RMS has been using the local SYSTEM account for the service account, you will need to specify a domain user account during the upgrade to AD RMS.
•            If you used the offline enrolment option to provision RMS, ensure that the enrolment is complete before upgrading to AD RMS.
•           Flush the RMS Message Queuing queue to ensure that all messages are written to the RMS logging database.
•           If RMS was provisioned using a hardware security module (HSM), you must reinstall the HSM drivers after the upgrade to Windows Server 2008 is complete, but before you start the upgrade to AD RMS.
•           If you are using a port other than 80 to host your RMS cluster, the AD RMS Upgrade Wizard will bind two ports to this Web site during the upgrade. You must remove the incorrect binding and restart Internet Information Services before the AD RMS cluster can service requests.
•            Custom access control lists (ACLs) that are applied to the Administrator and Group Expansion virtual directories are not migrated during the upgrade. If you have a custom ACL on either of these directories, you must set it up manually after the upgrade.
•            After completing the upgrade to AD RMS, you may receive the following error message when opening the AD RMS console
•             A connection with the specified AD RMS cluster could not be established. Cannot read configuration file due to insufficient permissions.
•            You must restart Internet Information Services (IIS) to correct this error.
•            If RMS is installed but not provisioned and you upgrade to Windows Server® 2008 R2 the upgrade link still appears in Server Manager. If you click this link and RMS was not provisioned, the upgrade fails.

Other things like exporting server licensor certificate and its key is also required to be saved and exported to new server, Update the CNAME records for new ADRMS cluster , check the ADRMS console and see if everything works fine.

licencing requirements for ADRMS?

Which type of licencing do we need for ADRMS?

Rights management service role in windows server gives you functionality to protect your files or emails with RMS templates and avoid unauthorised access of the documents. Many times I have been asked about the prerequisites for licencing as its vital thing while going for planning and budgeting for the same. We definitely need a licensed version of windows server to demonstrate the same feature in demo set up environment. In addition to it we also need something called ad CALs (Client Access Licenses) which are of two types for RMS server as well as for clients.

Hence you need following licence schemas

• Windows Server 2008 R2 Server License
• Windows Server 2008 Client Access Licenses (Windows Server CALs)
• Windows Rights Management Services 2008 Client Access Licenses (RMS CALs)

This means along windows server 2008, which provides you the ADRMS feature you additionally need server CALs for every machine serving as ADRMS servers and the entire user machines which use or create RMS templates to have client CALs.

There is another option called RMS 2008 External Connector (EC) which gives any organization an option to provide unlimited access to external users to ADRMS server hence no need of acquiring additional CALs for external users. The Windows Server 2008 EC license may be used as an alternative to Windows Server 2008 CALs.

For further information please go through the following links

http://technet.microsoft.com/en-us/library/dd772659%28v=ws.10%29.aspxhttp://microsoftplatform.blogspot.in/2012/07/windows-server-2012-licensing-faq-and.htmlhttp://mctexpert.blogspot.in/2010/08/do-you-need-extra-license-for-ad-rms.html 

Extending the Evaluation Period of Windows OS

Most of us working in IT Infrastructure management and service management industry would have worked upon evaluation versions of operating systems for test purposes most of them come  with expiry period of 60 days and after that they might behave differently ; like it may forcely boot or screen might go black etc.

In such situations we can go for extending the OS evaluation period for around 240 days wiht rearm command .But don’t use the rearm command until and unless your evaluation period is finished else it might waste the remaining evaluation period. Hence it is advisable to check the remaining evaluation period before we go for rearm command.

In order to check how much of evaluation period is remaining please perform following steps on your system (Here I was using Windows Server 2008 R2)

1.   1.   Go to START type CMD right click on CMD and select Run as administrator for elevated privileges 

h  2.   A prompt would appear shown as below click on yes

   3.  Now type slmgr.vbs  –dli (software licence manager command; -dli Display license information)in command prompt which would return message from windows script host something like this which tells how many days are left with evaluation period

   4.  If it shows very less time left with evaluation period then you can reset the evaluation period to additional 60 days as a grace period with rearm (rearm: Reset activation timer and initialization) command as follows

      You are done and good to go additionally if you want to check the grace period expiration details for that system you can type slmgr.vbs –xpr which will  provide you the expiry details of the grace period.