Troubleshooting Process Elevation in Privilege Manager

Oct. 12th 2016

Here are some tips when trying to discover why the process elevation feature is not working as expected.

  • Ensure that the rule has been created, has been saved and applied to a Group Policy Object (GPO). Ensure this GPO has been linked to either an OU or the domain.
  • Ensure that the Privilege Authority Client is installed on the client machine by looking in the Add/Remove Programs applet. If WMI is available, you can query the machine by dropping into a command prompt and typing “wmic /node: <fqdn of machine> product get name,version “.  If you need PowerShell, there is a great script located here.
  • From the command prompt, run ‘GPUpdate /force’ to make sure that the Group Policy has been refreshed.
  • Run ‘GPResult’ (or ‘GPResult /R’ on Windows7 or 2008), and check that the GPO the rule belongs to has been applied to that machine.  You can also use the Resultant Set of Policy (RSoP) feature or Group Policy Modeling on the Group Policy Console.  For more info, see here.
  • Check in the registry for the rule. Rules are copied to the key –

HKEY_LOCAL_MACHINE\Software\ScriptLogic Corporation\Privilege Authority\CSE\CSEHost\Host. Under this key you will see a key which is the SID for each user (i.e. S-1-5-21-15….) and then a unique GUID for each rule underneath this. To match the SID to a user account, navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and look at the data in the ProfileImagePath value or use the script provided below.

You can also create a VB Script using the following script:

Set oShell = CreateObject( “WScript.Shell” )



strComputer = “.”

Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

Set objAccount = objWMIService.Get(“Win32_UserAccount.Name='” & User & “‘,Domain='” & UserDomain & “‘”)

DisplayString = UserDomain & “\” & User & ” = ” & objAccount.SID

Wscript.Echo DisplayString

Wscript.Echo objAccount.SID

  • If the rule is present in the registry, enable logging to troubleshoot further.

 To Enable Logging


Under the registry key HKLM\Software\ScriptLogic Corporation\Privilege Authority\ change ‘LogLevel’ from the default value of 0 to 3 and restart the ScriptLogic Privilege Authority Host Service.  The log files can be found in the folder specified in the ‘InstallPath’ value under this same key. The default log location is C:\ProgramData\Privilege Authority\Logs.

  • Run the application or target process that you have created your rule for. Then go to the log file folder (by default – C:\ProgramData\Privilege Authority\Logs) and open the CSEHostEngine.log file. Every process that is being run by the user will be displayed.  To the right of each process, you will see a “MATCH” or “NO MATCH” status indicating whether or not the process matched a given Privilege Authority rule. Then, do a search for the process that you are trying to elevate and see if there is a match or not.
Posted by LeadThem Consulting | in Uncategorized | No Comments »

Using Exchange 2013 Logs to Troubleshoot Migration Issues

Aug. 15th 2016

During a Quest Migration for Exchange, you may run into problems that can delay or even halt the migration.  Quickly pinpointing the issue can get your migration back on track.  One way of achieving this is to review the logs of the affected systems.  Exchange 2013 has an enhanced set of logging capabilities that can assist you with troubleshooting issues that might arise during your migration.  The three Transport services can each log information over and above the normal event messages they might register in the system’s Windows application event log. Some of these activities are common to all three services, while other logs are maintained by specific services.  Most likely, these logs won’t be used on a daily basis, but can prove useful when troubleshooting connectivity.

There are three types of logs that all of the Transport services can independently maintain:

  • Connectivity logs capture information of all connections to a server. Logging is on by default. The default path Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\Connectivity will log entries for ordinary SMTP delivery and every other significant server-to-server connectivity event. Other components might log different data in the con­nectivity logs, too, although connectivity logs don’t show the details of protocol-level conversations.
  • Receive protocol and send protocol logs show the details of conversations: which party to the conversation said what and what the response was. The default setting for these logs are off. You would enable them only if you suspect problems with a specific protocol’s connectivity because the logs are quite verbose. It’s a good practice to note when they are enabled so they can be turned off after troubleshooting.

In addition, individual services maintain a number of logs. The following table summarizes the log types by component.

Service Log type Notes
Front End Transport Agent log Logs actions and configurations taken by agents.
Mailbox Transport Mailbox delivery agent Records actions taken by the Mailbox delivery agent only.
Mailbox submission agent Records actions taken by the submission agent.
Transport Active user statistics This log records user activity, including the number of messages and bytes sent or received. You can’t disable this log type.
Agent Logs agent actions for the Transport service.
Information Rights Management This log shows activity related to trans­port decryption of information rights management (IRM) messages.
Message tracking These logs are used to power Get-MessageTrackingLog and the rest of the message tracking functionality in EMS and EAC.
Queue These logs record queue actions, such as freezing or resuming queues.  You can’t turn queue logging off.
Routing table The routing table logs are a set of XML files that outline the routing topology Exchange uses; the logs are updated periodically. They used to be viewable with the Routing Log Viewer in Exchange 2010, but that tool was dropped in Exchange 2013.
Server statistics The server statistics log contains detailed information about the server’s activity, including the number and size of mes­sages sent and received, the number of DSNs generated, and the calculated end-to-end latency for message transport.

Logging Control

The Exchange Admin Center (EAC) has a very limited set of controls for logging behavior. Use the Transport Logs tab of the server properties dialog box to enable message tracking and connectivity logging and to change the paths for those logs and the send and receive protocol logs.

The Transport Logs section of the Organization Transport Settings dialog box allows you to control message tracking and connectivity logging.

The Exchange Management Shell (EMS) allows for more control of logging. Each of the services’ log­ging behavior for a service can be changed with the appropriate Set- cmdlet for the target service. For example, if you want to change how FET logs events, you’d use Set-FrontEndTransportService with the parameters to specify the options you want. Each of the logs supports parameters that control whether logging is enabled, how big log files may grow before a new log is created, and how long logs are kept. Each of these parameters has a name that begins with the type of log (AgentLog, ConnectivityLog, IRMLog, et cetera), followed by the parameter name (MaxAge, Path, and so on). When you know this, it is fairly easy to construct commands to do what you want done. For example, you might customize the connectivity logging behavior as follows:

Get-TransportService | Set-TransportService –ConnectivityLogEnabled $true –ConnectivityLogPath c:\logs\Connectivity –IrmLogEnabled $true –IrmLogPath c:\logs\ADRMS

Logs are named with a prefix (CONNECT, RECV, and ACTVUSRSTAT are examples) plus the date; some logging subsystems also include other items. The first log created on a day is named using a convention of YYYYMMDD-1.log where YYYYMMDD represents the year, month, and day. For example, the first active user statistics log created on March 2, 2014 is named ACTVUSRSTAT1.020140302-1.log. By default, Exchange creates a new log after it captures 10 MB of data in that log file. (You can adjust this with the LogMaxSize parameter.)

Each log type has a maximum size which defaults to 250 MB. A circular logging scheme keeps the logs in the directory under this size by removing the old­est logs to free up space for new logs. You can increase the amount of storage assigned to connectivity logs by setting the value like this:

Set-TransportService –Identity <Exchange Server>  –ConnectivityLogMaxDirectorySize 500MB

Assuming the directory storage threshold is not exceeded, logs are normally retained for 30 days. Because only the most recent logs are typically used to debug connectivity problems, you might decide to reduce this period. For example, here’s how you would set the reten­tion period for the connectivity logs on a server to 15 days:

Set-TransportService –Identity <Exchange Server> –IRMLogMaxAge 15.00:00:00

Protocol Logging

Combing through protocol logs can be tedious. It’s easy to miss fine details, and the process of correlating log entries across multiple servers is painful unless you can automate it, which might be easier than you think. Microsoft has a tool called LogParser (available from that gives you a query engine that works against several flavors of log file. You construct queries using an SQL-like syntax, and LogParser runs them against the log sets you specify.

If you’re familiar with SQL, then LogParser will be easy to understand. If you’re not, there are many examples of various queries and reports of use for Exchange on the Internet, and a few web searches will quickly find samples that you can adapt to get the data you want.

That’s it for this installment of Troubleshooting Exchange 2013.  Utilizing these logs in conjunction with the logs from the Quest Migration Tool should help you to quickly pinpoint and resolve any issues you may encounter during your migration.

Posted by LeadThem Consulting | in Migration Manager for Exchange | No Comments »

SharePlex – Repairing a Table with Copy

Jan. 2nd 2014

This procedure is generally used only for very large tables when standard compare and repair can not be executed due to time or system resource constraints.  The instructions below will allow you to execute this procedure with the least amount of impact to the database, by minimizing the lock time required on the table.

  • Open 3 windows on the source system to expedite the process. This will enable you to minimize the amount of time the full table lock is held. With proper execution, the table lock can be less than 10 seconds.
  • In one window, create an export parameter file to export the table you want to synchronize. When complete, enter the export command but don’t hit the return key. The basic export command or data pump can be used.
    • noup / expdp parfile=exp.par &
  • In your second window, enter sqlplus from the command line. Enter the lock table command but do not hit return.
    • sqlplus / as sysdba
    • SQL>  lock table <table name> in exclusive mode;
  • In your third window, enter sp_ctrl and type in the flush command but do not hit return.
    • sp_ctrl
    • > flush <datasource>
  • You are now ready to start the procedure. All steps should be done as quickly as possible to reduce the lock time.
  1. Execute the lock table command in window two. If this times out, retry until successful.
  2. Execute flush command in window three.
  3. Start export command in window one.
  4. Return to window two and execute a commit.
  5. When export is completed, transfer dump file to target server, truncate the table, and import it.
  6. Start the post process.


Author: Mark Bochinski, Senior SharePlex DBA, LeadThem Consulting





Posted by LeadThem Consulting | in SharePlex | Comments Off on SharePlex – Repairing a Table with Copy

SharePlex Compare and Repair

Jan. 2nd 2014


The COMPARE and REPAIR commands are essential components of the Shareplex toolset. The COMPARE command, started on the source system, will compare one table with the corresponding table on the target. The COMPARE USING <config file name> command will compare the entire list of tables in the config file. The COMPARE command creates one log file on the source and two files on the target, one log file and one SQL file. The log file records the steps taken and errors if they occur. The SQL file contains comments plus any SQL statements needed to bring the table back in sync. However, these SQL statements are not executed. During the execution of the COMPARE command, a brief exclusive table lock is required on the source system. The table is immediately unlocked once Shareplex starts reading the table. However, on the target system the exclusive table lock is held for the duration of the compare on that table. This prevents the table from being modified during the compare. The REPAIR command works identically to the COMPARE command with the exception that it does execute the SQL statements and synchronizes the OOS (out-of-sync) table.

Before starting the COMPARE or REPAIR commands, the TEMP tablespace and the UNDO tablespace may need to be made larger. Also, the undo_retention database parameter may need to be increased. At a bare minimum, the TEMP tablespace will need to be at least as large as the largest table. Depending on the setting of SP_DEQ_THREADS (default 2), the size of the TEMP tablespace would need to be larger than the sum of bytes of the two largest tables. If SP_DEQ_THREADS is set to a larger number, increase the size of the TEMP tablespace accordingly. Similarly the UNDO tablespace may need to be increased. Based on transaction volume and the length of time it takes to compare the largest table increase the size of the UNDO tablespace and increase the undo_retention database parameter to avoid an ORA-1555 Snapshot too old error. Tables with LOBs take much longer to compare or repair than tables without them.

The Shareplex COMPARE and REPAIR commands work as follows. After locking the table, the table is read and sorted in identical fashion on both source and target. If the table is large, it will probably need to be sorted in the TEMP tablespace. As this writes to disk, it will take longer than if it was sorted in RAM. Next, 10000 rows are read on the source and target systems, a UNIX check sum is performed. If the check sums match, the next 10000 rows are read, etc. If the check sums do not match, the COMPARE and REPAIR processes determine which rows are out of synch and creates the SQL statements to repair them. The REPAIR process executes the SQL statements.

Commonly modified COMPARE/REPAIR parameters

SP_DEQ_BATCHSIZE – Default 10000.This parameter determines how many rows are read on source and target before executing the UNIX check sum command. Larger batch sizes increase the processing speed but require more RAM. The range of values is from 1 to 32767.

SP_DEQ_THREADS – Default 2. This parameter controls the number of parallel compare or repair processes. It only impacts the COMPARE USING <config file name> command. A common occurrence when this parameter is set to a high value is multiple large tables comparing at once. If the database has 1000 tables in replication and 20 of them are large, Shareplex will quickly compare the small tables while the large tables will take longer as they sort to the TEMP tablespace. Eventually, many large tables could be comparing at the same time. This can cause a huge load on the OS. Setting SP_DEQ_THREADS larger than the number of available CPUs is unadvisable.

SP_DEQ_SKIP_LOB – Default 1. The default value causes LOBs to be included in the compare/repair process. Setting it to 0 will cause only the non-LOB columns to be included in the compare repair process. This will greatly speed up comparing or repairing LOB tables, especially useful if the LOB columns are never modified after insert.


Author: Mark Bochinski, LeadThem Consulting Senior SharePlex DBA





Posted by LeadThem Consulting | in SharePlex | Comments Off on SharePlex Compare and Repair

LeadThem Consulting
20418 SE Hwy 212
Damascus, OR 97089