Microsoft Management Console (MMC) saved query

The saved queries function in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in lets you create, save, and organize queries that you'll use repeatedly for administering Active Directory (AD) objects. 

You can create queries using the wizardlike options on the New Query dialog box, or you can define custom searches that can be used to gather whatever objects you like simply by keying in your own LDAP queries.

Here are the steps to follow in the Active Directory Users and Computers console to create a Custom Search saved query:

1. Right click the Saved Queries folder and select New, Query.
2. Enter an appropriate Name and Description.
3. Make sure the query root is set to the domain level you want the query to pertain to.
4. Select the Include subcontainers check box if you want the query to search all subcontainers.
5. Click Define Query.
6. In the Find dialog box, click the Find drop-down arrow and select Custom Search.
7. On the Advanced tab, enter your LDAP query string into the Enter LDAP query box.
8. Click OK twice.

What follows is a list of queries that can help you administer AD—and get you started on the road to using saved queries to simplify AD management.

Groups Like Service (finds any group name that contains the word service)

(objectcategory=group)(samaccountname=*service*)

Description Like Service (finds accounts in which the description contains the word service)

(objectcategory=person)(description=*service*)

Groups Like Admin (finds any groups whose name contains the word admin)

(objectcategory=group)(samaccountname=*admin*)

Universal Groups (finds groups with universal scope)

(groupType:1.2.840.113556.1.4.803:=8)

Groups with No Members (finds groups that have no members in them)

(objectCategory=group)(!member=*)

Note: The ! symbol means "Not" and * means "Has a value," so the combination of the two evaluates to “Doesn’t have a value.”

Global, Domain Local, or Universal Groups (finds any group defined as a Global Group, a Domain Local Group, or a Universal Group)

(groupType:1.2.840.113556.1.4.804:=14)

Global, Domain Local, or Universal Groups with No Members (finds any group defined as a Global Group, a Domain Local Group, or a Universal Group that has no members)

(groupType:1.2.840.113556.1.4.804:=14)(!member=*)

User Like Service (finds any account ID that has a name containing the word service)

(objectcategory=person)(samaccountname=*service*)

Password Does Not Expire (finds user accounts with nonexpiring passwords)

objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536)

No Employee ID (finds any user account that has no employeeid value)

(objectcategory=person)(!employeeid=*)

No Login Script (finds accounts that don't run a logon script)

(objectcategory=person)(!scriptPath=*)

No Profile Path (finds accounts that don’t have roaming profiles)

(objectcategory=person)(!profilepath=*)

Must Change Password and Not Disabled (finds nondisabled accounts that must change their password at next logon)

(objectCategory=person)(objectClass=user)(pwdLastSet=0)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)

UserList Exclude Disabled Account (finds all user accounts except those that are disabled)

(objectCategory=person)(objectClass=user)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)

Locked Out Accounts (finds all locked out accounts)

(objectCategory=person)(objectClass=user)(useraccountcontrol:1.2.840.113556.1.4.803:=16)

Domain Local Groups (finds groups with Domain Local scope)

(groupType:1.2.840.113556.1.4.803:=4)

Users with Email Address (finds accounts that have an email address)

(objectcategory=person)(mail=*)

Users with No Email Address (finds accounts with no email address)

(objectcategory=person)(!mail=*)

Connectors on JBoss

 

Connectors on JBoss 

Implementation of the J2EE Connector Architecture (JCA)

JCA is a resource manager integration API whose goal is to standardize access to non-relational resources in the same way the JDBC API standardized access to relational data. 

The purpose of this notes is to introduce the utility of the JCA APIs and then describe the architecture of JCA in JBoss.

 

JCA Overview

J2EE 1.4 contains a connector architecture (JCA) specification that allows for the integration of transacted and secure resource adaptors into a J2EE application server environment. 

The JCA specification describes the notion of such resource managers as Enterprise Information Systems (EIS). 

Examples of EIS systems include enterprise resource planning packages, mainframe transaction processing, non-Java legacy applications, etc. 

The reason for focusing on EIS is primarily because the notions of transactions, security, and scalability are requirements in enterprise software systems. However, the JCA is applicable to any resource that needs to integrate into JBoss in a secure, scalable and transacted manner. 

In this introduction we will focus on resource adapters as a generic notion rather than something specific to the EIS environment.

The connector architecture defines a standard SPI (Service Provider Interface) for integrating the transaction, security and connection management facilities of an application server with those of a resource manager. 

The SPI defines the system level contract between the resource adaptor and the application server.

The connector architecture also defines a Common Client Interface (CCI) for accessing resources. 

The CCI is targeted at EIS development tools and other sophisticated users of integrated resources. The CCI provides a way to minimize the EIS specific code required by such tools. 

Typically J2EE developers will access a resource using such a tool, or a resource specific interface rather than using CCI directly. The reason is that the CCI is not a type specific API. To be used effectively it must be used in conjunction with metadata that describes how to map from the generic CCI API to the resource manager specific data types used internally by the resource manager.

The purpose of the connector architecture is to enable a resource vendor to provide a standard adaptor for its product. A resource adaptor is a system-level software driver that is used by a Java application to connect to resource. 

The resource adaptor plugs into an application server and provides connectivity between the resource manager, the application server, and the enterprise application. A resource vendor need only implement a JCA compliant adaptor once to allow use of the resource manager in any JCA capable application server. 

An application server vendor extends its architecture once to support the connector architecture and is then assured of seamless connectivity to multiple resource managers. 

Likewise, a resource manager vendor provides one standard resource adaptor and it has the capability to plug in to any application server that supports the connector architecture. 

 Figure 5.1. The relationship between a J2EE application server and a JCA resource adaptor

 

The application server is extended to provide support for the JCA SPI to allow a resource adaptor to integrate with the server connection pooling, transaction management and security management facilities. This integration API defines a three-part system contract.

• Connection management : a contract that allows the application server to pool resource connections. The purpose of the pool management is to allow for scalability. Resource connections are typically expense objects to create and pooling them allows for more effective reuse and management.
  
• Transaction Management : a contract that allows the application server transaction manager to manage transactions that engage resource managers.
  
• Security Management : a contract that enables secured access to resource managers.
  

 

 

 

 

First Aid of JVM Crash Issues

Java Virtual Machine is a Native engine which allows our Java Applications to run. 

It performs the code optimization to improve the performance. 

In correct tuning, Low memory allocation, extensive code optimization, bad garbage collection strategy, API code leaking…etc are some of the reasons which may cause the JVM to crash.

Analyzing a JVM Crash is one of the very interesting and little time taking process sometimes it is even little complex to find out the root cause of the JVM Crash. 

Here in this article we will see some of the common mistakes, first aid solutions/debugging techniques to find out what kind of informations we can get by looking into the Core Dump.

What is Core Dump & Where to Find It?

Code dump is usually a Binary file which gets generated by the Operating System when JVM or any other process crashes. 

Sometimes it also happens that the JVM will not be able to generate the Crash dump. 

In Windows Operating Systems it will be generated in the Directory where the “Dr. Watson” tool is installed. 

In Windows it will be usually:  

”C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson“

By default in Unix based Operating Systems the Core Dump files are created in the directory where the Java Program/Server was started even sometimes it is generated in the “/tmp” directory of the Operating System. 

But using the following Java Option we can change it’s the Crash Dump/Heap   Dump generation locations:  -XX:HeapDumpPath=/opt/app/someLocaton/ and  -XX:+HeapDump JVM Options.

NOTE: These Flags does not gurantee that always the Heap/Crash dump will be generated at the time of JVM Crash. There are some more reasons behind the Core Dump not gets generated…like Process Limitations or the Less Disk Quota or unavailability of the Free File Descriptors.