Tuesday, August 9, 2011

Escape from Expensive Licensing: RemoteApp

Nowadays, the cost involved in the user license for some applications are too high. But off course we cannot avoid this, but for an extent can be minimized smartly by using the RemoteApp. Though RemoteApp is not the first to exist, prior can be done via Citrix.

For example just think about common application used internally which has the per user license, can be published in RemoteApp, in turn used for n number of users.

But there are high end application cover this loop holes, their licensing terms have the virtualizing license terms and also blocked the feasibility of terminal session publish options. As long as the application allows as to work smoothly in RemoteApp, no harm in using it. This can save some serious money for your organization.



Directory Partitions in Active Directory:

We will discuss on the directory partitions in active directory and its purpose served in the windows domain environment. The active directory database is logically separated into directory partitions:
Schema partition
Configuration partition
Domain partition
Application partition
Each partition is a unit of replication, and each partition has its own replication topology. Replication occurs between replicas of directory partition. Minimum two directory partitions are common among all domain controllers in the same forest: the schema and configuration partitions. All domain controllers which are in the same domain, in addition, share a common domain partition.
Schema Partition
1. Only one schema partition exists per forest.
2. The schema partition is stored on all domain controllers in a forest.
3. The schema partition contains definitions of all objects and attributes that you can create in the directory, and the rules for creating and manipulating them.
4. Schema information is replicated to all domain controllers in the attribute definitions.
Configuration Partition
1. There is only one configuration partition per forest.
2. Second on all domain controllers in a forest.
3. The configuration partition contains information about the forest-wide active directory structure including what domains and sites exist, which domain controllers exist in each forest, and which services are available.
4. Configuration information is replicated to all domain controllers in a forest.
Domain Partition
1. Many domain partitions can exist per forest.
2. Domain partitions are stored on each domain controller in a given domain.
3. A domain partition contains information about users, groups, computers and organizational units.
4. The domain partition is replicated to all domain controllers of that domain. All objects in every domain partition in a forest are stored in the global catalog with only a subset of their attribute values.
Application Partition
1. Application partitions store information about application in Active Directory.
2. Each application determines how it stores, categorizes, and uses application specific information. To prevent unnecessary replication to specific application partitions, you can designate which domain controllers in a forest host specific application partitions. Unlike a domain partitions, an application partition cannot store security principal objects, such as user accounts. In addition, the data in an application partition is not stored in the global catalog.
As an example of application partition, if you use a Domain Name System (DNS) that is integrated with Active Directory you have two application partitions for DNS zones -- ForestDNSZones and DomainDNSZones:
ForestDNSZones is part of a forest. All domain controllers and DNS servers in a forest receive a replica of this partition. A forest-wide application partition stores the forest zone data.
DomainDNSZones is unique for each domain. All domain controllers that are DNS servers in that domain receive a replica of this partition. The application partitions store the domain DNS zone in the DomainDNSZones.
Each domain has a DomainDNSZones partition, but there is only one ForestDNSZones partition. No DNS data is replicated to the global catalog server.
The below are some useful commands related to the application partitions in NTDSUTIL,

Creating and deleting application directory partitions,
#CREATE NC dc=application,dc=example,dc=com server.example.com
#CREATE NC dc=application,dc=example,dc=com null
#DELETE NC dc=application,dc=example,dc=com

Creating and deleting replicas,
#ADD NC REPLICA dc=application,dc=example,dc=com server2.example.com
#ADD NC REPLICA dc=application,dc=example,dc=com null
#REMOVE NC REPLICA dc=application,dc=example,dc=com server2.example.com
#REMOVE NC REPLICA dc=application,dc=example,dc=com null

Defining a replication schedule,
#SET NC REPLICATE NOTIFICATION DELAY dc=application,dc=example,dc=com 10 15

Displaying replica information,
#LIST NC REPLICAS dc=application,dc=example,dc=com



Organizations are only as good as their current system being used. This system encompasses all processes ranging from human capital down to the various aspects of operations such as production, quality assurance and even disaster preparedness. In this regard, an organization can only survive if it employs certain strategies that will make it live longer. Two of these strategies are the BCP and the DR. These two strategies or disciplines are related because both of them help the organization from being disrupted from any untoward variables either internal or external in nature.

BCP is completely known as Business Continuity Planning. The definition of such a term is really easy for the term already speaks of what it is all about ‘“ continuity of the business. It is simply the state of being ready for any unforeseen incident that can disrupt the day to day process or operation of businesses and organizations alike. Hence, it is a good management strategy wherein the organization is ensured that it can always maintain its standards and service levels even if there are some challenges that come its way.

In addition, BCP is a preventive and proactive strategy of ensuring business continuity. It therefore helps in lessening the probable damage that could have resulted if there were no safety preparations employed prior to the incident.

On the other hand, DR or Disaster Recovery is obviously recovering from a disaster. It is the strategy of intelligent recuperation from a negative incident of any magnitude. Thus, DR is simply a reactive approach. It is more of a treatment given to a disease rather than a preventive measure. Nowadays, the trend or focus for both BCP and DR is on the IT or information technology of the organization. With major operations being mostly shouldered by computer applications and automated programs, these businesses prioritize saving or healing their IT system above all else. Any organization will not argue that they really don’t want to be offline or un-powered for a lengthened duration.

All in all, Disaster Recovery or DR is, without a doubt, not similar BCP because:

1. BCP stands for Business Continuity Planning whereas DR is Disaster Recovery.
2. BCP is a proactive strategy whereas DR is a reactive approach.
3. BCP helps prevent and anticipates a disaster or unfavorable incident in advance whereas DR is a strategy that treats or recovers from disasters and the like.

Hope the above is informative.