Jump to content

Gregg

Root Admin
  • Content count

    259
  • Joined

  • Last visited

  • Days Won

    8

Gregg last won the day on June 20 2016

Gregg had the most liked content!

Community Reputation

9 Neutral

1 Follower

About Gregg

  • Rank
    Level 6 Contributor
  • Birthday 04/08/1969

Contact Methods

  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Richmond, VA

Recent Profile Visitors

1,846 profile views
  1. Terminiology

    The following is a list of terms used in descussing different aspects of CA Service Desk Manager. Term Description $NX_ROOT refers to the installation directory of Service Desk
  2. Project Management Module

    Hello Jorge, This is a user community for CA's Service Desk Manager, so it doesn't surprise me in the least that there are no discussions about the Project Management module in Manage Engine's Help Desk. A quick search turned up this: https://forums.manageengine.com/servicedesk-plus. Hopefully, you can find the help you need over there. Thanks, Gregg
  3. I guess the position could still be open, but realize that this opening was originally posted almost 6 years ago.
  4. CA Unicenter Consultant

    I guess it is possible that this position is still open, but please note that it was originally posted over 3 years ago.
  5. Thanks for updating and the rebirth of SDU. I think the content is useful and always a source to help for me and my work with CA SDM. Best regards, Peter Bech-Lutzka

  6. Overview CA does not provide a GUI supported method for creating or modifying Condition Macros or Action Macros. However, the function that these types of Macros provides can be crucial. This article explains the steps to take for creating new or editing existing. Keep in mind, CA does not support any changes to the default Action Macros or Condition Macros and will not support any that you create. It is also highly recommended that you never modify the defaults, but rather copy them and create your own custom ones. Procedures Step 1. Extract a Sample Macro The first step is to extract a macro from the system and use this as guide. Take note of the macro's name the enter the following command: pdm_extract -f "SELECT del,fragment,lock_object,ob_type,sym,type FROM Spell_Macro WHERE sym = 'sample macro name'" > yourfile.txt Step 2. Add Your Script Now that you have the sample macro extracted from the system, modify the contents of the 'fragment' column to suit your scripting needs. Remember to use \\0012 for your carriage returns and \ to cancel out the double quotes in your script. Also, be sure to change the value of the 'sym' column or your new macro will not be loaded. Step 3. Load New Macro Run the following command to load your new macro into the system: pdm_load -f yourfile.txt -i -v Step 4. Extract New Macro for Additional Changes Run the following command to extract your new macro if additional changes are required: pdm_extract -f "SELECT * FROM Spell_Macro WHERE sym = 'sample macro name'" > yournewfile.txt Step 5. Uploading Changes Run the following command to load your modified macro into the system: pdm_load -f yournewfile.txt -v Notice there is no -i this time. A -i is only used when "inserting" a new macro, not when editing an existing one.
  7. Events and Macros

    Overview Starting with the r11.x releases, events and macros are managed in the web client. Prior to r11, they were managed in the java client. Events Events are the combination of a condition and one or more actions. They are attached with tickets via Service Types, Service Contracts, or custom code. If an event is attached to a ticket, it will trigger after a defined period of time. When an event is triggered, it's condition is evaluated and will return either True or False. Any actions associated with the condition evaluating to True or False are then executed. Macros The conditions and actions that are used in defining Events are done using macros. While condition macros evaluate to either True or False, action macros allow for just about any action possible within Service Desk. Below are explanations and examples of the two types of condition macros (Condition Macros and Site-Defined Condition Macros) and 4 types of action macros (Action Macros, Attach Event Macros, Multiple Notification Macros, Remote Reference Macro). Site-Defined Condition Macro Site-Defined Condition Macros are a special kind of condition macro. There are no site-defined condition macros included in a fresh install of Service Desk. They are created by the client. While the Site-Defined Condition Macros provide an easy to use interface and offer vast flexibility, they do not offer as much flexibility as Condition Macros. Condition Macro When a site-defined macro won't do the job, it is time to use Condition Macros. A fresh install of Service Desk contains quite a few to start with. There are no default capabilities for managing Condition Macros within the administration interface. Since they are written in Spell code and Spell code is not officially supported by CA, take special caution when working with them. To add new Condition Macros, see How To Manage Spell-Based Macros. It is highly recommended that you do not modify ANY of the default Condition Macros. If changes are needed, create a new one based on the original. It is best to reference existing Condition Macros to understand the coding that is needed. Action Macro Action Macros are typically used to set field values, such as increasing Priority or setting the SLA violation. However, since they are written in Spell code, they can perform just about any action possible within Service Desk. A fresh install of Service Desk contains quite a few to start with. There are no default capabilities for managing Action Macros. To add new Action Macros, see How To Manage Spell-Based Macros. It is highly recommended that you do not modify ANY of the default Action Macros. If changes are needed, create a new one based on the original. It is best to reference existing Action Macros to understand the coding that is needed. Attach Event Macro Attach Event Macros are used to attach another event. This allows for complex branching in your conditioning as well as on going processing. Multiple Notification Macro Multiple Notification Macros are the most commonly used type of macros. They are used to send out notifications. Unlike Activity Notifications, Events combined with Multiple Notification Macros add more flexibility with notification. However, by default, Multiple Notification Macros do not provide HTML email support. Remote Reference Macro Examples Condition Macros Site-Defined Condition Macros Action Macros Add Custom Activity Log Attach Event Macros Multiple Notification Macros Remote Reference Macros
  8. Data Partitions

    Overview Data Partitions are subsets of the database with restricted access based on their content. A Data Partition restricts access with a defined set of constraints. The Data Partitions are associated with Contacts via their Access Type. For legacy purposes Data Partitions can also be associated with a Contact Record directly, however this is not a recommended method. Controlled Tables Constraints can only be created for tables in the Controlled Tables list. There is no GUI supported method of adding tables to the Controlled Tables list, but the process can be achieved via a data load. Example load: TABLE Controlled_Table del desc obj_name sym { "0" ,"Activity Log tables" ,"alg" ,"Act_Log" } { "0" ,"Change Activity Log tables" ,"chgalg" ,"Change_Act_Log" } { "0" ,"Issue Activity Log tables" ,"issalg" ,"Issue_Act_Log" } Constraint Types Create - New records must satisfy this constraint before a save can be completed. Defaults - Sets default values to be set on an empty field of a new record. Delete - Specifies what records can be deleted by the user. Pre-update - Identifies the records that can be updated by the user. Records not satisfying this constraint can only be view as read-only. Update - Updated records must satisfy this constraint in order to be saved. View - Identifies the records that can be viewed. Example Constraints Column Properties Table Type Syntax Description Act_Log Pre-Update id = 1 Prevents the update of Activities in the Request, Incident, and Problem Activity Log.* Ca_Contact Pre-Update id = @root.id Only permit update of your own Contact Record. Ca_Contact Pre-Update id = U'00' Prevent updating of any Contact. Ca_Contact View last_name NOT LIKE 'KT%' Prevent display of any Groups beginning with the letters 'KT' Ca_Contact View (last_name NOT LIKE 'Group_Name') when we insert the above to access type; that access type wont be able to see the above group name Call_Req Create customer = @root.id Allowing only the creation of tickets where you are the End User Call_Req Default type = 'I' Create an Incident Call_Req Default category = 'pcat:400001' Set a default Request/Incident/Problem Area Call_Req Default group = U'807AEA15E8A2CF4ABF9181CBFEA12899' Set a default Group Call_Req Delete id = 1 Prevent the deletion of any tickets Call_Req Pre-Update customer = @root.id Allowing only the updating of tickets where you are the End User Call_Req View customer = @root.id Allowing only the viewing of tickets where you are the End User Call_Req View organization is null Allowing only the viewing of tickets where the organization is null Call_Req View organization is null Allowing only the viewing of tickets where the organization is null Call_Req Create customer.last_name NOT LIKE '% %' Allowing ticket creation for contacts that don't have a certain string of characters in their last name Change_Act_Log Pre-Update id = 1 Prevents the update of Activities in the CO Activity Log.* Change_Request Create id = 1 Prevents the creation of a new Change Order Cr_Status View code IN ('ACK','OP','RE','WIP') Display a set list of Status Options Prob_Ctg View sym like 'Application' Display only the Application Areas Workflow_Task Delete task != 'APP' Prevents the deletion of the Approval task. Workflow_Task Delete status = 'WAIT' OR status = 'PEND' Prevents the deletion of completed tasks. Workflow_Task View status != 'SKIP' Prevents view of the SKIP status. History This article was originally a wiki article created by Gityerfix in 2008 and later modified by BrianM, Rajkumarrt, Paul_thompson, Agegeleruvy, FrankTR, Bz0rvc, and Amullendarby.
  9. Configuration Items

    Determining Uniqueness The following fields are used to determine the uniqueness of a CI: Name Serial Number Asset_Num System Name DNS name Mac Address History This article was originally a wiki article created by Gityerfix in 2008.
  10. Auto-Assignment

    Overview Auto-assignment is the functionality that is intended to automatically set the ticket Assignee based on various factors, such as End User Location, Workshift, and Analyst availability to name a few. The process flow below helps to understand the thought process behind the auto-assignment process. History This article was originally a wiki article created by Gityerfix in 2008.
  11. Migrating the wiki pages

    I am in the process of converting the old wiki pages to articles. Below are a list of pages I am currently not planning on migrating. If you think any of them might be of value, please let me know and I will consider migrating them. Migrating 6.0 to r11 Test Patch T5ET051 Test Patch T5GQ012 Test Patch T5GQ027 Test Patch T3GQ028 Attachments Library (about configuring an v6-r11 migration) Note: I am still in the process of converting wiki pages. I will update this list if I encounter any additional wiki pages that I decide to skip.
  12. Overview The following are the steps to build a test system mirroring a production system. It involves getting a sql backup of mdb, with all login's in the backup and then restoring is to a test system that has been setup and have an existing mdb built. The existing mdb is copied over using the SQL restore. Procedures install the base product run the pdm_configure to setup and ensure the environment is correct. backup $NX_Root/site/mods on the production system do the following extract on production pdm_extract wspcol > wspcol.txt pdm_extract wsptbl > wsptbl.txt restore the wspcol / wsptab to the test system pdm_load -f wspcol.txt pdm_load -f wsptbl.txt delete the file $NX_Root/site/mods/wsp_schema.log (may not be present) log on to the Web Screen Painter open the Schema Designer open any table and make a dummy update (e.g. the description some place) choose 'File' -> 'Save and Publish' shutdown the Unicenter Service Desk services run pdm_publish start the Unicenter Service Desk services check for any errors sign on to Service Desk sign on to sql visual studio verify that any schema changes are in place check the ddict.sch found in $nxroot\site verify fields are in the ddict copy $NX_Root/site/mods to the test system (see step 3) run the pdm_configure to setup and ensure the environment is correct. check ddict.sch found in $NX_Root/site, to make sure that the fields were added correctly restore the database using SQL change the database name in the following table dlgtsrv table change the primary server name to the test server name sym from production name to test name server from production name to test name change all the notifications in the usp_contact record to 'Notification' c_cm_id1, c_cm_id2, c_cm_id3, c_cm_id4 SQL Command is update dbo.usp_contact SET c_cm_id1 = 1801, c_cm_id2 = 1801, c_cm_id3 = 1801, c_cm_id4 = 1801 reboot the server before running pdm_configure, check the following User ServiceDesk is active and available Update ServiceDesk in the SQL database apply patches History This article was originally a wiki article created by Gityerfix in 2008 and edited by Revans and Eziril. Gregg updated to remove version number from the text while converting it to an article.
  13. Overview This article provides guidance and insight into the best use of the Request Areas (to include Incident Areas and Problem Areas), Configuration Items, and Root Causes. Misuse of Request Areas Request Areas are probably the most misused items in Service Desk. Most companies seem to want to use the field to classify the tickets for reporting purposes. This results in a very extensive list of Request Areas but with very granular reporting potential. This is because reporting on the Request Area field is limited to the items in the Request Area list. If it's not in the list then you can't report on it. Usually this abuse of Request Areas can be attributed to the company recreating the system that Service Desk was purchased to replace. The true purpose for Request Areas are to assist in routing a ticket to the appropriate Group or Analyst for resolution. A good rule of thumb is to start with the same number of Request Areas as their are routing potentials. Typically if there are 20 Groups, then there are 20 routing potentials. Then add new Request Areas as needed, such as when Properties are required. But do not create a Request Area for every application and every type of problem that an application can have. There are other fields that will give you this information... and do so with broader reporting potential. Using the Fields for Their Intended Purpose The Affected End User identifies the WHO. Who is the person requesting support? Who is the person requesting information? The Configuration Item (aka Asset) identifies the WHAT. What is the item that the End User is requesting support for? What is the item that the End User is requesting information on? The Root Cause identifies the WHY. Why is the End User requesting support? Why is the End User requesting information? The Request Area simplifies the routing to the appropriate Group or Analyst equipped to handle the End User's request. The Hidden Potential of Configuration Items When Request Areas are misused, the listing is almost always done in a manner that categorizes the Request Areas. For example, there will be a folder for Software and another for Hardware and yet another for Network. And then maybe Software will have a sub folder of Business Apps and maybe another for IT Tools. And a concern for limiting Request Area use would be that this categorization would be lost. But this couldn't be farther from the truth. Configuration Items contain a Class and Family structure by default which exist for the sole purpose of classifying the CIs. The Family/Class structure can be designed to mimic that which has been put in place for Request Area. Another overlooked reality with Configuration Items is their wealth of information. When you look at the details of a Request Area you get very little. Maybe a Default Group, a Service Type, Description, and a few Properties. But the details of a Configuration Item has far more potential such as Family, Class, Manufacturer, Warranty Expiration, Service Type, Priority, Organizations, Inventory Count, Parent CIs, Child CIs, etc... And all of these items can be reporting on. Using Root Cause The key to using Root Cause is remembering they were designed to answer the simple question of WHY? Why did the End User request support for there email? Because there was a network failure and Outlook was unable to connect to the Exchange Server. Why did the End User request assistance with their flash drive? Because a training deficiency resulted in the user's lack of understanding. See the Root Cause article for more examples. Reporting Potential As stated before, if using Request Areas to classify your tickets, your reporting on Request Areas is limited to the number of items in the list. So if there are 100 Request Areas then you have 100 items to report on. You can certainly combine items, but you are still limited to the words that make up your Request Areas. But by limiting your Request Area listing and using Root Cause and Configuration Items to better classify your tickets, the reporting potential explodes. Lets say you have configured your system with 20 Request Areas, 100 Configuration Items, and 25 Root Causes. You can now report on any combination of the three. This gives you the reporting potential that far exceeds the capabilities of the Request Area field alone. For example, 20 Request Areas X 100 Configuration Items gives you 2000 reporting possibilities (20 x 100 = 2000). Now add 25 Root Cause and you have 50,000 reporting possibilities (25 x 2000 = 50,000). And these are just the numbers when using one Request Area, one Configuration Item, and one Root Cause. The reality is that you can combine any number of each. And finally, you also have all the attributes of the Configuration Items that you can report on. History This article was originally a wiki article created by Gityerfix in 2008 and edited by FunkDoC.
  14. Survey Best Practices

    Overview A survey is of no value if the end user doesn’t complete it. Creating a valuable survey goes far beyond the questions that are being asked. It involves the entire presentation. Below are a some suggestions for increasing the number of survey responses as well as the quality of the responses. Suggestions Unique Subject Line When configuring your survey email message, have the subject line differ enough from other Service Desk generated email. This will make the survey invitation stand out and hopefully avoid any email client rules that may delete Service Desk generated emails. Incentive Offer an incentive in the email message body. The value gained from the surveys far exceeds the cost of a small incentive. Perhaps something along the lines of Complete a Survey for a chance to win one of five $50 gift cards. This is just one extra little thing that can be done to increase the completion percentage. Limit the number of questions Once you have enticed the users to access the survey, you now want to ensure they complete the survey. You do this by keeping the survey simple and only having a handful of questions. A good rule of thumb is 4-6. Maintain question and answer consistency Maintain a consistency between the questions and the answer scale. This makes for an easy to complete survey that the user is likely to complete again in the future. Example Questions: How satisfied are you with the support technician’s attempts to understand your issue? How satisfied are you with the amount of time it took for a support technician to respond to your issue? Both questions are satisfaction questions which would utilize the same answer scale. This makes it easier for the user to interpret, navigate, and complete the survey. Example Answer Scale: Strongly Dissatisfied | Dissatisfied | Satisfied | Strongly Satisfied | N/A No Middle Option Notice in the example answer scale above there is no neutral middle-ground option. This ensures that the user is committing to either a positive response or a negative response. Providing a Neutral or Neither Agree or Disagree option is like a magnet and many users will use this option which greatly handicaps the value surveys offer to IT. Leave a Way Out Do not force a user to answer a question they do not feel comfortable answering. Either do not make the questions required or add an N/A option to the answer scale for each question. For Survey reports, unanswered or N/A answered questions should be excluded and not influence the total count of asked questions. Provide Equal Opportunity It is important that everyone who opens a ticket be given an opportunity to provide feedback about the report they received. To ensure this happens, the survey frequency must be set to 1. Setting the frequency to a value higher than 1 provides a greater opportunity to those who open more tickets as they have a greater chance to receive a survey invitation. However, setting the frequency to 1 will result in the potential for users to get way too many survey invitations during the life of the survey. This can be very annoying and damaging to the effectiveness of the survey. So to avoid this, configure the survey to ‘Use Stricter Rules’. This ensures that a user only be able to complete a single survey within its lifestyle. Survey Trends Run a Survey for a quarter then retire it. Make an exact copy of the survey and activate the copy. Repeat this process every quarter. This ensures that the same questions are continuously being asked which allows for a quarter-by-quarter comparison between survey results. When ‘User Stricter Rules” is utilize, activating a new survey every quarter will give all users a new opportunity to provide feedback. A new quarterly survey using strict rules ensures that no user will submit more than 4 surveys a year and that every user who opens a ticket will have an opportunity to provide feedback at any time during the year. History This article was originally a wiki article created by Gityerfix in 2008
  15. SDU 2.0

    We're back! And there have been some changes! What did NOT change? SDU is using the same forum software All forum content is intact All wiki content is (or soon will be) available under the Articles section The Articles section will be editable by users, like the wiki was Everyone's accounts, passwords, and content are all intact What DID change? The wiki interface is gone The forum software has been upgraded (7 years overdue!) Reputation system - you can "like" posts and other content Social Media - you can share content to many different social media sites The original layout/look of the site has been replaced with a standard template, in an effort to bring the site back online quickly Advertising - for the moment, the advertising has been removed New host - the site is now hosted by the makers of the forum software. This is more expensive, but should result in easier maintenance and timely software upgrades. What caused SDU to shut down in the first place? Okay, so a few weeks ago, the previous company hosting SDU suspended the account because someone found a way into my account and either both malware files throughout the file system as well as attach malware code to existing, legitimate files. We're talking over a thousand affected files in a sea of over 15,000 files. At first, it looked like a manageable set to review one at a time and fix/delete. However, I soon realized just how pervasive the damage was and realized it was not reasonable to fix everything. And the host would not reactivate the account until the malware had been removed. On top of that, my host account was about to renew for another 2 years' of service. I saw no easy way to get SDU back up and operational, so I decided to pull the plug. I did NOT want to do that, and hated to see all of that content just disappear. So, why is SDU back in business? Well, mainly because of you. In the weeks since shutting down SDU, I've received quite a few emails from you guys thanking us for hosting SDU, offering stories of how SDU has helped you in the past, and many, many offers to help bring the site back or at least make a copy of the content available. I decided to break out the defibrillator and see if I couldn't get find a way to revive SDU. This is the result! I hope you like it! Gregg
×