Troubleshooting Desktop Authority

Oct. 10th 2016

As with any computer program, especially a management application such as Desktop Authority (DA), there will be times when you’ll be required to troubleshoot issues that may be encountered while using the product.  This is a brief overview of the log files produced by DA to assist with troubleshooting.

There are three categories of log files we can view when troubleshooting issues with Desktop Authority.

  • Manager (console) log files
  • User Based Management client log files
  • Computer Based Management log files

Let’s look at all three categories in more detail.

Manager Log files

These log files can be found on the Manager Console machine and depending on the OS, are found in different locations.

— W2k3 = %ALLUSERSPROFILE%\Application Data\ScriptLogic\DAConsole\

— W2k8 & W2k12 = %PROGRAM DATA%\ScriptLogic\DAConsole\

  • The DAConsolelog records general activity encountered during the launching of the manager console.
  • The DAConsole_errors.log records any errors or exceptions encountered when launching or running the manager console.
  • The SMWinServicelog – records all activity related to the Desktop Authority Manager Service.
  • The SMWinService_errors.log – records any errors or exceptions encountered when launching or running the Desktop Authority Manager Service.

User Based Management Client Log files

These log files can be found on the client machine under %TEMP%\Desktop Authority.

  • The SLTrace.htm file is used primarily to troubleshoot User Based Management settings executed during the logon event.
  • The SLTraceEnforce.htm file is used to troubleshoot User Based Management settings executed during the refresh event.
  • The SLTraceLogoff.htm file is used to troubleshoot User Based Management settings executed during the logoff event.
  • The SLBoostlog file is used to record activity encountered when attempting to provision the target machine.
  • The SLInstallog file is used to record activity encountered when attempting to provision the target machine with the DACIientlnstall.msi.
  • The SLAgentlog ffle is used to record details of activity recorded in the trace files, but mainly pertaining to the Run As Admin feature.

Computer Based Management Client Log files

These files are located on the client machine in %WIN DIR%\Temp\Desktop Authority.

ComputerManagementTrace.htm file is used to record the activity for all computer based management settings on a daily basis.

The SLTraceUSLoc.htm file is used to record the locator activity.

 

Hopefully these files, in addition to regular windows event logs and other systems can help you to quickly pinpoint and resolve any issue you encounter when using the product.  Good luck and happy computing!

Posted by LeadThem Consulting | in Authentication Services | No Comments »

The Decision to migrate has been made. Now What!?!

Oct. 12th 2015

You’re the IT guy and the company has been bought, changed names, or your just simply cleaning up old Ailing domain that should have gone years ago. There are a few things you need to do before seeking out quotes for software and beginning your Active Directory Migration. A few questions to ask:

  • How many users will be migrated?
  • How many mailboxes will be migrated?
    • How much Email Data do you have?
  • How many Domains will be migrated?
  • What time frame you want to complete?

You now have your Software now what do we need to know before we start migrating.

  • What Applications talk to AD and how?
    • Are they LDAP?
    • Can they be configured with multiple domains?
    • Contacting the Vendor sometimes will help with these questions.
  • Do you have a List?
    • Users
    • Groups
    • Computers
    • Users to Computers they use
    • Users to Shared Mailboxes they use

Having these things ahead of time will help you and your consultant move forward faster and more efficient.

Posted by LeadThem Consulting | in Migration Manager for Active Directory | Comments Off on The Decision to migrate has been made. Now What!?!

Performing an Intra-Forest migration

Oct. 8th 2015

Performing an Intra-Forest migration is different in many aspects than performing an Inter-Forest migrations. The biggest issue that needs to be watched out for is not having two same accounts with same SIDS in both domains. That is why as soon as possible after migrating the objects they need to be deleted from the source domain. This make having a tested backup extremely important in case there is a need to back out the migration. Careful planning needs to be done when performing an Intra-Forest migration. Below are high level steps to help insure that the migration goes smoothly.

  1. Upgrade source Global groups to Universal
  2. Physically migrate all groups to target Domain.
    1. Migrate groups with Sid History and adding source members.
    2. Delete source groups
    3. Change admin point to target for all groups.
    4. Resource Process workgroup data (i.e., file servers, etc.)
    5. Execute ADPW in all domains to update group membership of Source users
    6. Optional but recommended:  Clean up sidHistory on migrated groups.
  3. Create user “stubs” in target. (i.e., Logically Migrate)
    1. Migrate user accounts, skipping sAMAccountName (migration session)
    2. DO NOT copy SID History, Password, Security Descriptor, and Mailbox.
    3. DO NOT Enable user account
  4. Resource process and move all workstations. (delete the source computer accounts during the physical migration – if QMM Directory Sync is running, be sure NOT to sync deletions)
    1. Exclude serviceprincipalname attribute from computer objects
  5. Resource process servers for ACL only
  6. Migrate users (Physical Migration)
    1. Verify RMAD session ran recently (in case of an object restore requirement)
    2. Migrate selected users with Password, SID History, Mailbox, and sAMAccountName
    3. Run ADPW with custom map to update TARGET ‘Update Group Membership”. Verify migration
    4. If SQL servers present, SQL Wizard run with custom map
    5. Delete source users
  7. Migrate Servers (physical migration)
    1. Resource Process (do not double acl, replace the acl).
    2. Join to target domain
  8. Clean-up
    1. If MS SQL present, re-run SQL Wizard with all objects.
    2. Re-run ADPW, clean up legacy memberships.
    3. Verify RMAD run and user ADPW to cleanup SID History.
    4. Remove source domain.

Note that you may choose to “loop” on step three for sets of users at a time.  You may also choose to loop on step 2 for sets of groups at a time

Posted by LeadThem Consulting | in Migration Manager for Active Directory, Migration Manager for Exchange | Comments Off on Performing an Intra-Forest migration

How To Redirect the Default Website to the Password Manager(QPM) Self Service Site

Jan. 22nd 2014

Password Manager does not auto redirect the website you have to go to http://servername/qpmuser every time. However with in IIS you can turn out HTTP Redirect. Here are the steps.

Go to the IIS Manager
Select HTTP Redirect under the Default Web Site

pic1

 

Check “Redirect request to this destination”

Enter QPMUser

Check “Redirect all requests to exact destination”

Check “Only Redirect Request to content in this directory”

Click Apply

pic2

Go under each subfolder and Virtual site of Default Web Site

Uncheck “Redirect request to this destination” this is very important due to every subfolder and virtual site will be set for HTTP Redirect.

Apply Changes

pic3 pic6 pic5 pic4

 

Once this is done you will be able to go to http://servername and it will redirect you to http://servername/QPMUser

This Must be done on all QPM Webservers you want to Redirect

 

Note: If you want to redirect to Helpdesk Enter QPMHelpdesk instead of QPMUser

 

 

Author: Wayne Thompson, Exchange Architect, LeadThem Consulting

 

________________________________________________________________________________________________________________

 

 

Posted by LeadThem Consulting | in Password Manager | Comments Off on How To Redirect the Default Website to the Password Manager(QPM) Self Service Site