(2010-06-20) ADMT v3.2 Has Been Released

"The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations."

Download it from here.

Additional info about ADMT can be found here and here.

Latest ADMT Migration Guide can be downloaded from here.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2010-05-19) Information About Upgrading To Windows Server 2008 R2 AD

If you are interested in reading information about upgrading to Windows Sever 2008 R2 AD, then make sure to check the following links/docs:

• Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (DOC)
• Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (WEB)
• Upgrading Domain Controllers: Microsoft Support Quick Start for Adding Windows Server 2008 or Windows Server 2008 R2 Domain Controllers to Existing Domains
• Running ADPREP To Upgrade the AD Forest/Domain

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2009-11-09) Migrating Your Local Users, Local Groups And Memberships From The SAM Into AD

You may have a Windows Server somewhere that’s not joined to a joined that contains lots of local user accounts, local groups and of course memberships of local accounts in those local groups. On that server you have permissioned all NTFS permissions with those local groups. Another scenario is a member server with exact same information. Now you have decided you want to "migrate" all of that into AD. How would that be possible easily without loss of information?

REMARK: Before you do this, as a fallback plan, make sure to have a FULL backup of the server you want to perform this operation on!

The starting point would be something similar to the pictures below.

All Users

All Groups

All Group Memberships

In these pictures you see local users and local groups and those users are member of those local groups. The way to keep that all is to promote the server to a DC in a NEW AD domain. Because of that the information is kept and "migrated" into AD (into the ‘Users’ container). If you promoted the server into an existing AD domain, the information in the SAM would be lost.

In this example I’m promoting a member server in an AD domain into a new AD domain in the same AD forest. After promotion of the member server into a new AD domain in the existing AD forest, the end result is shown below.

Migrated Users and Groups

Migrated Group Memberships

Migrated User Properties

By doing it this way, you migrate the info into AD and when that has occurred you can use ADMT to migrate the objects into some other AD domain. The fun part is that in the second migration into another AD domain, you will not have issues regarding the membership rules when migration between AD domains in the same AD forest!

More specific information about the upgrade process can be found here.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2009-10-04) Upgrading ILM 2007 To FIM 2010 – What To Do?

SOURCE: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/b47c5545-b066-45bd-9e21-9601f5a7fa86

In the ILM 2 Forum the following question was asked:

What’s the upgrade path to go from MIIS/ILM 2007 to FIM 2010? Will FIM 2010 just use your current configuration? Also, how’s the timing of the FIM release? If you were implementing Identity Management now – is it best to implement it on ILM or FIM?

Bob Tucker from Oxford Computer Group answered:

1. The upgrade path from ILM 2007 to FIM 2010 involves several steps, but generally will not be terribly difficult. You would need to accomplish the following:
   
2. Stand up a test environment that represents your production environment
   
3. Upgrade your SQL database to 2008 if not already there
   
4. Recompile all code using .Net 3.5 (Visual Studio 08)
   
5. Perform complete end to end testing
   
6. Verify you have x64 versions for any third party apps required on the ILM server (Oracle client, Notes client, etc)
   
7. Build Windows 2008 x64 and install FIM 2010 sync engine – pointing to the SQL 2008 version of the ILM database
   
8. Perform complete end to end testing
   
9. Consider installing FIM 2010 portal
   
10. Consider migrating some of the codeless capabilities and group management to FIM 2010
    
11. Perform complete end to end testing
    

As you can see from above – FIM 2010 can make use of your existing design, but it is not a point and click upgrade (one is 32 bit only, the other 64 bit only).

Timing of the release of FIM 2010 can best be answered by some of the MS guys – they have the latest information.

As for which one to use – if you are just now getting into the process of implementing an identity management solution, you should start with determining systems involved, gathering requirements, developing a design, etc. If you absolutely require the use of a portal to allow user participation, then you may want to wait on FIM 2010 (or look at designing your own); if you are looking to deploy in the immediate future, you will have to decide whether or not you can use release candidate software in a production environment. With the release of RC1 of FIM 2010, you may be able to participate in TAP/RDP programs if desired.

As you can see from the migration path; if you decide to start with ILM 2007, you can still migrate the capabilities to FIM 2010 without too much work, though it may involve some rework to move some of the design into the portal.

David Lundell from Ensynch answered additionally:

In step 3 You will need to change some of your references to use 64-bit editions of the new Microsoft.metadirectoryservicesex.dll that was introduced with the hotfix referenced below: http://support.microsoft.com/default.aspx/kb/946797.

I can’t understate the importance of following Bob’s advice in Step 5. 64 bit editions of the items needed is critical. For example the Host Access Management Agents are not yet available for 64-bit use since they depend on Host Integration Server 2006 which won’t install on Windows Server 2008 x64. So if connect to mainframes you will need to consider how to do that:

1. using ILM 2007 as a bridge
   OR
   
2. using a 3rd party MA
   OR
   
3. writing your own MA
   

My personal comments:

With regards to "timing release", the known official release date/period is Q1 2010.

Should you use ILM 2007 or FIM 2010? Basically what ILM 2007 is able to do, FIM 2010 is also able to do. Big thing you need to take into account is the architecture. ILM 2007 is 32 bit only and FIM 2010 is 64 bit only. Any dependency on THAT needs to be investigated. As already mentioned, if you need additional client software for an MA (Oracle, Notes, SAP, etc.) to work and you want to use FIM 2010, make sure 64 bit client software is available!

If you need portal functionality, such as users need to interact with ILM/FIM for whatever reason (e.g. self-service password reset, other self-service stuff, group management, etc.) you are better in using FIM 2010. It does not mean it is not possible to do it with ILM 2007. What it does mean is that ILM 2007 itself cannot do it, but you need s solution external to ILM for those features.

The sync engine in FIM 2010 differs from ILM 2007 in the following ways:

• Supports both scripted provisioning and codeless provisioning
  
• Supports both inbound/outbound attributes flows and inbound/outbound sync rules
  
• Automatic hierarchical provisioning (creating directory structures if they do not exist) (ILM 2007 support this also, but rather in code)
  
• Equal precedence (meaning "last sync wins" and allowing the merger of multi-valued attributes such as the member attribute in group objects)
  

With regards to licensing, for the Sync Engine you just need a server CAL, but if you want to use the features of the Portal you need user CALs in addition.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2008-07-15) Migration Support In ADMTv3.1 For Windows Server 2008

In this post I explain what you can do with ADMTv3 and what you cannot do. Additionally I also define common migration steps and provide links to other information sources. ADMTv3.1 has been released a few days ago and it now supports Windows Server 2008 based servers. If you need to use ADMT on W2K3 use ADMTv3 and look at this post.

Like ADMTv3 could only be installed on a W2K3 server, ADMTv3.1 can only be installed on a W2K8 server. Additionally the "Password Export Server" is available as a separate download for both 32 bit and 64 bit computers. Microsoft also updated the migration guide.

System Requirements

• Supported Operating Systems: Windows Server 2008
  
• ADMT can be installed on any computer capable of running the Windows Server 2008 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.
  
• Target domain: The target domain must be running either Windows 2000 Server or Windows Server 2003 or Windows Server 2008
  
• Source domain: The source domain must be running Windows 2000 Server, Windows Server 2003, or Windows Server 2008
  
• The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
  

The following is available:

• ADMT v3.1 (only supports W2K8 servers, but supports all AD versions)
  
• Password Export Server version 3.1 (x86) (supports W2K, W2K3 and W2K8 servers)
  
• Password Export Server version 3.1 (x64) (supports W2K, W2K3 and W2K8 servers)
  
• Guide for Migrating and Restructuring Active Directory Domains Using ADMT v3.1

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2006-12-27) Migrating Stuff With ADMTv3

ADMTv3 has been out for a while and is the free Microsoft Migration Tool available for use (besides other small tools that can help you during your migration like NETDOM, SUBINACL, ROBOCOPY, etc.). It can be downloaded here

Besides the tool you can also view and download documents with loads of info about migrations and how to use ADMT. The following information is available:

• ADMT v3 Migration Guide
• How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003
• Windows 2000 Server Domain Migration Cookbook

 

ADMTv3 is a migration tool that can help you with:

• Migrating user and group objects (with or without sIDHistory) from one domain to another
• Migrating computer objects and the actual computers from one domain to another
• Translate stuff (from source domain –> target domain):
  • Security on file based data ACLs
  • Security on printers ACLs
  • Security on shares ACLs
  • Security on registry ACLs
  • Security on profiles ACLs (and registry information)
  • Service Accounts used by services
    • REMARK: make sure you identify the custom service accounts FIRST on each server to be migrated. This also prevents the option "change password at next logon" being set as the user account is migrated. All accounts NOT identified as service accounts will have the option set. If needed you can revert this afterwards with ADMOD/ADModify
  • It CANNOT help you with:
    • Translate security on services ACLs. For that you can use SUBINACL
    • Translate information within IIS and COM+. For that you need to use a third party tool
    • Translate information within SQL. For that you need to use a third party tool
    • ….other apps…. –> For that you might need to use a third party tool

 

Interesting enhancements within ADMTv3 when compared to ADMTv2:

• When migrating between AD forests, it is aware of possible schema differences between the AD forests
  • It allows to define attributes for exclusion during migration
  • Schema differences (attributes that are not migrated) are shown within the migration logs
• SQL or (W)MSDE database support
  • Enables and supports the use of multiple consoles
• The possibility to select source and target DCs for migrating objects
• It supports INPUT files for objects to be migrated
• It allows the rename of objects during migration (through the use of an input file)
• Performing pre-migration tests to ensure availability of computers to be migrated
• Additional options when migrating passwords like:
  • "Do not update passwords for existing users"
  • Migration of changed passwords from source domain
• The "Password Export Server (PES)" can be configured to run with a service account. This enhancement removes the dependency on the "pre-Windows 2000 compatible access" group that PREVIOUS should contain the well-known security principals "Everyone" and "Anonymous Logon" (in W2K only "Everyone" as that by default already contained "Anonymous Logon") (in W2K3 you can revert to the same behavior but that IS NOT recommended!)

 

NOT that of an enhancement:

• It can only be installed on Windows Server 2003

 

When migrating from one domain (source) to another domain (target) the following are high-level steps to consider:

• Make sure the target AD has been configured (sites, subnets, replication, OUs, GPOs, delegations, DNS, WINS, DHCP, etc.)
• Setup name resolution (WINS or DNS) between source and target domain/forest
  • REMARK: When either endpoint of a trust is NT4, you must use NetBIOS name resolution which is made possible by WINS or LMHOSTS. When either endpoint of a trust is W2K or higher, you can either use NetBIOS name resolution, which is made possible by WINS or LMHOSTS, or use DNS name resolution (I prefer the last!)
• Setup trusts between source and target domain
  • REMARK: When either endpoint of a trust is NOT W2K3, you must use an external trust. When either endpoint of a trust is W2K3 or higher, you can either use an external trust or a forest trust. For the latter, which one you use depends on the environment and your requirements.
    Be aware that sIDFiltering is by default enabled on the outgoing part of an external trust (which therefore impacts the use of sIDHistory AND/OR the use of external domain group membership within the same target forest)
    sIDFiltering is by default NOT enabled on the outgoing part of a forest trust (which therefore does NOT impact the use of sIDHistory AND/OR the use of external domain group membership within the same target forest). Some documents might mention sIDFiltering is enabled by default on the outgoing part of a forest trust. This is not true!
    When sIDFiltering is enabled on the outgoing part of a trust and sIDHistory is used AND/OR domain external domain group membership within the same target forest, you need to disable it using the following command:
    • Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>
      (to ENABLE sIDFiltering again specify Yes)

 

SOURCE DOMAIN —————–(trust)—————–> TARGET DOMAIN
                              ^                                             ^
                               |                                              |
                               |                                              |
                               |                &nbsp
;                             |
                    outgoing part                           incoming part
(sIDFiltering is ALWAYS configured on the outgoing part of a trust – not saying if it is configured or not! Just saying WHERE)

Also see:

• When to create an external trust
• When to create a forest trust

• Setup migration accounts to be use with the migration tooling
  • REMARK: this really depends if you have a one-way or two way trust, what you want to migrate and if the source and or target domain are AD… see the migration guide for this!
• Install and configure migration tooling and if needed for password migration, also designate a source DC as the Password Export Server (PES) and install the required software
• Identify service accounts across servers in the source environment
• Migrate groups, user accounts with passwords and group memberships (with sidhistory)
  • REMARK: When resource access is provided by a sID, sIDHistory can help you. However if resource access is provided in another way (e.g. <domain><user or group>, or something else), you MUST add the target ACEs first before the users switch over to their new account. When not taken care of, resource access might be lost. Examples of applications where this can occur is SQL server.
  • REMARK: To use sIDHistory your target domain MUST be in at least "Windows 2000 Native" mode or domain functional level. Well, this is the supported configuration! There exists migration tooling that is able to migrate sIDHistory without the AD domain being in at least "Windows 2000 Native" mode or domain functional level, or in other words, still being in "Windows 2000 Mixed" mode or domain functional level. Remember, the latter is NOT supported by Microsoft! I also do not know that the impact is of this and what requirements might exist emposed by the migration tool.
• Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
• Migrate mailboxes if needed
  • REMARK: This is another story and it depends if you are migrating from Exchange 5.5 or Exchange 2000/2003
• Migrate servers to the new domain or migrate data to new servers
• Translate security (Re-ACL) and other stuff of the data/resources from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain) (see list above)
  • REMARK: Although you might have not yet translated security it might look like the ACLs already show security principals from the target domain. This DOES NOT mean security has been translated. This occurs when using sIDHistory as the target system recognizes the sID (because it is stored in the sIDHistory field) and shows the target security principal instead of the source security principal. If you would cleanup sIDHistory suddendly the source security principal is shown and if you additionally remove the trust an "unknown sID" is shown
• Cleanup temporary configurations
• Cleanup sidhistory (recommended!).
  • REMARK: sIDHistory is a temporary configuration and is used to access resources while those resources still have security descriptors from the source domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. sIDHistory should only be used temporary for migration purposes! To clean sIDHistory you can use ADFIND and ADMOD. The command line looks like:
    • For the complete target domain:
      • adfind -default -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
    • For just some OU within the target domain:
      • adfind -b "<DN of some OU>" -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
• Remove trusts
• Decommission old domain(s)

 

For more information about ADMTv3 and possible steps needed for migration see the ADMT v3 Migration Guide.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2006-12-01) Disentanglements And Migration Scenarios

A major company is disentangling a part of its business and that part is continuing on its own. It will not be integrated into another company.

Last week I was asked to review and advise several migration scenarios setup by a company’s representative.

Current setup/requirements:

• W2K3 based AD, upgraded from W2K
• Empty Forest Root Domain and 1x Child Domain
• All resources and objects are in the child domain
• Business part to be disentangled is only in the child domain. It has locations where it exists by its own and it has locations shared with other business parts
• As always: time is an issue!
• Business continuity is very important
• It was not clear if the businesses should be connected or not again in the future. Lets assume it may be needed in the future

Possible migration scenarios I had to review:

1. Clone the Empty Forest Root Domain and the child domain, where only those resource are cloned or separated that belong to that business part. Network will be disconnected.
2. Create a NEW AD forest/domain and migrate all the objects and resources from that business part into the new AD forest/domain
3. Clone the child domain and reposition it on a separate network and rename it to be the new forest root domain
4. Clone the Empty Forest Root Domain and the child domain, rename both to another name, connects networks and and migrate (?) resources from source to target

As you can imagine the first (1), the third (3) and fourth (4) scenario made me think if these were really migration scenarios to be considered for a company that size. Besides that, should they be considered at all?

Well, whatever…I’m going to try to explain ALL the scenarios and you will see what I think of all.

Ad.1

In this scenario an AD forest/domain (at least its contents) is cloned and resources are also cloned or separated. Resources are cloned if they are shared by both parties or are left behind or are moved into the cloned part, depending on who owns/uses it.

It is a "big-bang" scenario, because suddendy the AD forest is broken into two exactly the same parts. The forest and domain names are the same and the domain SIDs are the same.

With this scenario I only see disadvantages. Examples are:

• On both sides cleaning must be done and AD roles must be repositioned/established
• Both environments can NEVER be reconnected again to each other
• Both companies may experience serious security issues as both ADs have the same "ID"

IMHO, this is not an option!

Ad.2

In this scenario the sold business part designs, creates and deploys its own AD forest/domain. After that a migration plan is created, tested and executed to migrate ALL related objects and resources from the source AD to the new AD.

Activities include (very very very high-level):

• Inventory current environment and decide what needs to be migrated or not
• Decide if migration can be done with ADMTv3 and other MS tooling or if third-party tooling should be bought, licensed and used
• Build, deploy and configure new AD forest
• Connecting both ADs through name resolution and trusts
• Migrate groups, user accounts (service accounts) with passwords and group memberships (with sidhistory)
• Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
• Migrate mailboxes if needed
• Migrate servers to the new domain or migrate data to new servers
• Translate security (Re-ACL) of the data/resources/applications from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain ) (sID-based and name based)
• Cleanup temporary configurations
• Cleanup sidhistory (recommended!). sIDHistory is used to access resources while those resources still have security descriptors from the old domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. Sidhistory should only be used temporary for migration purposes
• Remove trusts
• Cleanup what is not needed in the source AD that was migrated

Advantages:

• Best known, supported and safest approach/scenario
• Phased approach
• Fallback is possible

IMHO, this is THE option to choose from!

Ad.3

In this scenario only the child AD forest/domain (at least its contents) is cloned. Resources remain in the source environment until the cloned child domain has been renamed AND repositioned as the new forest root domain.

The idea behind this scenario was to create a new AD forest (cloned from the previous and renamed) that has exactly the same domain SID to prevent re-ACL-ing resources/data/applications. Although that may be true for sID- based ACEs but you would still need to re-ACL name based resources (e.g. SQL –> <DOMAIN><USER or GROUP>)

Although renamed, as the domain is cloned you would still may have serious security issues as mentioned in scenario 1. However because it has been renamed I assume it would be possible to connect both networks. I wonder if it would be possible to create a trust? I guess not! You can read more about this in the next scenario.

Besides this all, there is one thing here that is technically IMPOSSIBLE at this moment. Although you can rename ALL the domains in a forest you can NOT transfer the forest root domain role to another domain in the forest. Other non-forest root domains can be repositioned. A forest cannot exist or function correctly without a forest root domain

IMHO, this is not an option!

Ad.4

This scenario is similar with scenario with the difference that both the forest root domain and the child are cloned and renamed. This scenario was born instantly are I explained what I described in scenario 3.

So the questions here are:

• Is a trust possible between cloned domains where the clone has been renamed?
  • –> NO!
• Is access possible from IDs in the cloned domains without re-ACL?
  • Yes, if it is sID based
  • No, if it name based
• What is the impact of having two exact the same forest/domains on the network while the clone has been renamed?
  • Security issues (same domain SID)
  • Probably too complicated
  • Probably too error prone
  • Too many unknowns
  • Probably not even supported by MS

IMHO, this is not an option!

Summarized:

So lets compare scenario 2 and 4….

• OK, users, passwords, groups and memberships are available in both ADs, How are you going to keep up with new people that need access to resources and/or new objects. How to keep stuff in sync? As soon as the migration starts the company does not freeze until the migration is finished.
• sID based re-ACL is not needed, however name based ACLs STILL need to be re-ACL-ed
• Clients and servers STILL need to be migrated

As you can see, with scenario 4 you might save time during a certain step, but it will take more time and probably be more complex in some other way.

Stick to proven scenarios that everyone uses, like in-place upgrades or migrations to other AD forests/domains. Do not take unnecessary known risks and unknown risks just to save a few dollars/euros and time. Those kinds of measure/solution will probably hunt you down at a later moment.

Ye
s, it is true upgrades and migration also have an impact on the environment. Remember that it has been done many times by all kinds of people.

So the correct option here is option 2: "Create a NEW AD forest/domain and migrate all the objects and resources from that business part into the new AD forest/domain". This scenario has less risks and does not impact business continuity like the other scenarios probably would.

BUT…..what do YOU think?

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————