(2019-12-12) Delivered Session About “Moving Towards Passwordless Concept”

Delivered session @DetronICT, invited by @ThierryVos about "Moving Towards Passwordless Concept" (preso and demos). About 30 tech enthusiasts listened until bitter end. Thanks for the invitation, and until a next time! Reward afterwards? Enjoying some beers together!

Figure 1: Initial Slide – Title/SubTitle

–

Figure 2: Introducing Me

–

Figure 3: The Agenda

–

Figure 4: The Agenda With Demos

– Cheers,

Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisement

(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: https://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: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2006-12-01) NT4, W2K3, Trusts And Security Policies

Last Tuesday (28-11-2006), almost at the end of the day, and old customer (Customer "X") called me and told me they were having issues with the interoperability between their NT4 environment (yes, they still exist! 😉 ) and their AD environment. As I had no important plans for that evening I decided to go and help them out.

The issue was that users in the AD environment (W2K3 SP1) were not able to access data in the NT4 environment and it was getting worse and worse. In that case there was a two-way trusts in place between the AD environment and the NT4 environment. The one-way trust from AD (outgoing) to NT4 (incoming) still worked, but not the other way around (from NT4 (outgoing) to AD (incoming)).

The trust was in place, but the secure channel died that day for some reason. Because of latency in AD replication I was able to see the trust password was last changed on the 21st and that it changed on that day (as expected – 7 days later).

Resetting the secure channel was not an option as one of the end points was NT4. To be able to do that with either DOMAIN.MSC or NETDOM both domains must be at least Windows 2000 Server based or later. So the only option was to recreate the trust. Because of the trust issues we tried multiple times to recreate the trust. Sometimes we were able to recreate or we got errors/messages like "access denied" or "could not find a domain controller"…

So lets examine this:

• The trusts (both ways) have been in place for years
• It has worked with the current configuration
• Adding NT4 security principals to AD security principals (membership) or AD resources (ACEs) worked
• Adding AD security principals to NT4 security principals (membership) or NT4 resources (ACEs) did worked until the trust from NT4 to AD broke
• AD groups or resources did NOT show unresolved SIDs
• NT4 groups or resources did show unresolved SIDs
• Creation of the trust sometimes succeeded but most of the times it did not.

First thought:

Something must either have changed that day to prevent the creation and configuration of the trust OR some configuration was put in place after the first trust creation years ago that allowed the trust to work until it broke

Thinking about this, it was time to check GPOs linked to the Domain Controllers OU and their GPO settings. Customer "X" only had the Default Domain Controllers Policy linked to the Domain Controllers OU and nothing else. The first thing we saw right away after comparing their policy settings (User Rights and Security Options) with the default configured policy settings. It was like comparing the colours black and white. The differences were huge!

Looking at the articles"MS-KBQ889030 ("Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected")" and "MS-KBQ823659("Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments")", the solution we all thought of was to relax the security settings on the AD side. We followed the recommendations as mentioned in the first article for the security settings. After that we were to recreate the trust and access to the NT4 resources from the AD side was restored.

Everyone was happy! Customer was happy as the business was able to continue to work the next day and we were able to go home and go to sleep. For me, the next day was an appointment with another customer about migration scenarios. It was midnight before I saw my bed. ;-(

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

(2006-12-01) Another VMware Issue?

About a year ago I found two issues in combination with VMware Workstation and W2K3 SP1. Both cases are explained here:

• It Works On Physical Hardware And It Does Not In VMware Virtualization Software
• Follow-Up On "It Works On Physical Hardware And It Does Not In VMware Virtualization Software"

I have been working a while with VMware Workstation 5.5.2 and I’m quite happy about it. The product is/works great! The feature I like most is being able to create all the snapshots I like. For testing purposes, demos, study, etc, it rocks!

With that same version I created an NT4 PDC and a W2K3 SP2 DC (B2805) to test some migration things with ADMTv3. So as you can imagine I configured both sides with everything needed (e.g. trusts) to be able to migrate objects with password and sIDHistory.

A day or so ago I found out VMware Workstation 5.5.3 was out and upgrade my VMware Workstation install. Since that time I had two crashes with VMware Workstation (which crashed my laptop – BSOD). I have never had a crash because of VMware Workstation. Better yet, I can’t remember the last time I had a crash. Besides that the environment I had built (NT4 and W2K3SP2) started to show some issues as well. To test something else I wanted to re-create the trust, but I was not able to. I got all kinds of messages like "could not find a domain controller on the NT4 side" and RPC errors on the W2K3SP2 side (don’t know the exact error anymore). This time I took a network trace and also saw the error. Trying to use the same solution as mentioned in the articles above did not work also. And no the security policies on the W2K3 side were not tightened!

Because of those two issues (crash and trust errors) I decided to revert back to VMware Workstation 5.5.2. Ahh… life was back to normal! Until now I have not had any crash and the trust in that environment worked again.

I must say, I have not tested this into all bits and bytes, but I thought I just mentioned it here in case someone else experienced the same. If you have similar experience, be so kind to post a comment here (also).

Thanks!

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

(2006-10-17) VMware And The Newest Vista And Longhorn Builds – UPDATE

A while ago I wrote about installing Longhorn/Vista builds higher than 5384 (through build 5600) within VMWare Workstation. That post can be found here:

https://jorgequestforknowledge.wordpress.com/2006/09/11/vmware-and-the-newest-vista-and-longhorn-builds/

A few days ago I downloaded the binaries for Longhorn build 5728 loaded it within VMWare to install a new server, and to my surprise the issue mentioned above did not occur. It just started without an issue! YES!!! 😉

BUT….as soon as I clicked "Install Now" the installation complained about a missing, but required, CD/DVD drive device driver. Oh man, noooooooo, not again….;-( Crap!

Fortunately I found the solution quite fast. The solution itself is also very easy!

Well, here it is:

• Use a current installed Vista/Longhorn build
• Copy C:WindowsInfCDROM.INF to a floppy (or floppy image)
• Copy C:WindowsSystem32DriversCDROM.SYS to a floppy (or floppy image)
• Load/insert it and click RE-SCAN.
• The installation should now find the CD/DVD drive device driver on the floppy. Click NEXT and continue your journey!

I must say that I do not know if the issue mentioned here also occurs within Virtual PC/Server and/or on physical hardware. If someone tries either or both be so kind to post a comment here about it. Thanks!

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

(2006-07-04) Restoring A DC Through The ASR Method

Today I was testing a restore method within a test environment for a DC using the ASR method with a third party backup and restore tool.

The restore went OK. The DC booted and everything was OK. Well, until other DCs were crying like:

* RPC unavailable

* Cannot reach DC in site X

* etc.

 

So the troubleshooting started:

* TCP/IP settings (IP, DNS and WINS) on the restored DC –> OK

* Checking DNS SRV RRs registration –> OK

* Checking DNS name resolution –> OK

 

Hmm..

The restored DC was able to inbound replicate from whatever DC, but other DCs were not able to inbound replicate with the restored DC.

As all DNS stuff was OK and there were no firewalls between the DCs WTF could this be…

It made me crazy and I was pissed about it. So I started the troubleshooting steps again from the beginning and suddenly I saw something strange! In status column for the LAN connection it showed: "connected, firewalled"….

What???? Firewalled….. I was absolutely sure the LAN connection was configured to be firewalled prior to the backup and there was NO GPO that configured the firewall on that DC or other DCs. I made sure the backup did not have the LAN connection firewalled!

 

Conclusion: for some freaky reason the ASR restore enables the firewall on the LAN connection during the restore. This was when using a third party backup and restore tool. Not sure if the native ASR restore from MS does the same.

 

For those who don’t know what an ASR restore is:

In short, it is a bare metal restore method where a mini OS is installed including the backup and restore client and after that the backup on the tape is restored to the DC.

You can find more info about ASR here:

• How ASR works
  • http://technet2.microsoft.com/WindowsServer/en/Library/7b4f0436-cc90-4b52-b6ab-064f9db8d2721033.mspx?mfr=true

 

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

(2006-05-17) Large Integers And VBS Or BATCH

For a script I was writing, I needed to work with large integers.

 

Example code in VBS was to compare very large numeric numbers:

Dim LargestValue
LargestValue=0
AR = Array("134234","22342399999999999994","9","555555555577698","6","5")
For l = 0 to UBound(AR)
    If LargestValue < Int(AR(l)) then
       LargestValue = Int(AR(l))
    End If
Next
wscript.echo LargestValue

As you can see 22342399999999999994 is the largest value and it should be returned as such. Well it does, almost…

However, it does not say (and that is what I would like!):

22342399999999999994

but it says:

2.23424E+19

As soon as a numeric value gets a certain size it converts it to x.xxxxE+y

Example code in VBS was to compare very large numeric numbers:

@ECHO OFF
CLS
SETLOCAL ENABLEDELAYEDEXPANSION
SET LargestValue=0
FOR /F %%I IN (NUMBERS.TXT) DO (
 IF /I !LargestValue! LSS %%I (
  SET LargestValue=%%I
 )
)
ECHO !LargestValue!

In this case it does return the largest value as I want…

So I thought, lets do it in batch. So before continuing I thought "let’s do another test of creating an addition of very large numbers". The code would look like:

@ECHO OFF
CLS
SETLOCAL ENABLEDELAYEDEXPANSION
SET NUMBER1=4611689999999999999
SET NUMBER2=500000
SET /A NUMBERTOTAL=%NUMBER1% ++ %NUMBER2%
ECHO %NUMBERTOTAL%

now guess what the output was!….

it was:

Invalid number.  Numbers are limited to 32-bits of precision.

 

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

(2005-11-24) Connecting The Test Environment To The Production – What Is Your Opinion?

As many of you already have done it, or are doing it right now, or better yet are still thinking about it! What? Well, migrating to Windows Server 2003 with AD.

 

When planning migration, on of the important is topics is thinking about the test environment to test the migration itself, but to also test current functionalities and especially current applications…

 

So when moving from an NT4 domain to Active Directory (based upon W2K3) you have two possibilities:

(1) Migrating from the NT4 domain to a newly fresh installed AD domain

With this you have the possibility to build a fresh installed AD domain, migrate everything you want to (groups, users, computers and resources) and leave all crap behind. It just looks like a fresh start.

PROs:

• Little to no impact on the current environment (much safer)
• Fallback migration scenario is much simpler
• Object migration is non-destructive
• No sudden introduction of new AD DCs into production environment
• Phased migration is possible
• Direct use of ALL new AD functionalities as no legacy DCs are used
• Ability to install and configure the new AD environment without even it already being used and without impacting current environment and better possibility to implement new wishes/requirements
• Better possibilities to test current available functionalities and applications

CONs:

• As migration contains more phases to accomplish, much slower
• Current NetBIOS name of NT4 domain cannot be reused. (unless the migration is performed twice using an Interim AD environment, or renaming it after the migration)
• Extra hardware needed for DCs
• Migration tooling needed migrate objects and re-ACL resources
• Objects must be migrated and resources must be re-ACL-ed

(2) In-place upgrading the NT4 domain to an AD domain

With this you have have the possibility to just either perform a software upgrade of all NT4 DCs to W2K3 DCs or only upgrade the PDC, introduce new W2K3 DCs and remove the old NT4 DCs

PROs:

• Ability to keep current NetBIOS name of NT4 domain
• Current domain configuration is used
• No extra or very little extra hardware needed
• Quick implementation/migration
• No tooling needed to migrate objects or re-ACL resources

CONs:

• When doing a software upgrade of DCs those DCs will be impacted and unavailable during a certain period (this is always true for the PDC)
• Eventual non-compatibilities (applications, services, drivers, etc.) on NT4 DCs must be solved by removing or upgrading to new versions prior to upgrading the OS.
• Fallback scenario’s are more difficult
• Limited use of new AD functionalities and only available after removal of all NT4 DCs
• Direct introduction of AD DCs prevents phased migration
• Implementation of AD without disrupting current environment is more difficult to realize
• More difficult to implement new configurations and to cleanup current crap
• Old default configurations may be kept instead of using new default configurations
• Less possibilities to test current available functionalities and applications

____

Building and using the test environment for scenario (2)…

Now, independent of the reason why you want to do an in-place upgrade of the current NT4 domain to an AD domain, to just test the migration you install a new BDC in the production domain and sync it with the PDC. You move that BDC into a test environment, and promote it to a PDC. For testing purposes you install an additional BDC in the test environment. To prepare for the domain upgrade you install 2 freshly installed W2K3 member servers, install and configure them with DNS/WINS/DHCP and configure them with "NT4Emulator" and "NeutralizeNT4Emulator" registry keys. After that reboot the servers!

So it’s time upgrade the NT4 PDC…but before doing so also configure it with the "NT4Emulator" and "NeutralizeNT4Emulator" registry keys and reboot the PDC.

After the PDC is up again the upgrade is started and after a while the first W2K3 DC has been introduced. That same W2K3 is also the first GC and hosts all FSMO roles. Followed by this is the promotion of the 2 W2K3 member servers to AD DCs. After the promotion these new DCs might be configured as GCs and the FSMO roles might be transferred to one of them.

As your environment may consist of legacy clients (you may need to update them first prior installing the first W2K3 DC with latest service packs and/or the DSClient) and W2K/WXP/W2K3 clients and server you may want to test authentication against NT4/W2K3 DCs, only W2K3 DCs and only NT4 DCs. If you are satisfied with the results you could remove the NT4 BDCs and the upgraded W2K3 DC. At this moment you are left with 2 W2K3 DCs and the Forest Functional Level is set to "Windows 2000" (choose if the domain will also contain W2K DCs) or "Windows Server 2003 Interim" (choose if the domain will only contain NT4 and W2K3 DCs). This choice is made during the upgrade of the NT4 PDC to a W2K3 DC. To stop the emulating stuff on the W2K3 DCs the "NT4Emulator" and "NeutralizeNT4Emulator" registry keys are removed and the DCs are rebooted. As soon as W2K/WXP/W2K3 clients and servers detect the W2K3 DCs not emulating anymore these clients and servers will upgrade their secure channel to use Kerberos for authentication instead of using NTLMv2.

So at this moment the migration has been tested and the results are satisfying. However, before doing this in production you just may want to test the (core) applications against an AD domain and additionally test the same applications against an AD domain in Forest Functional Level "Windows Server 2003". So how are you going to do this, if it is not possible to introduce those (core) applications on servers/systems into the test environment?

Now this is a wild and crazy scenario and I would love to know what you’re opinions are?

Discription of the wild and crazy scenario…

So at this moment you have 2 W2K3 DCs hosting a domain that is practically the same as in production (same name, sids, etc.)  These servers also host DNS and WINS. Only the two DCs, their names and IPs are different. As you use a server based computing (SBC) solution in your production environment, you install a WXP client and a SBC server in your test environment. On that SBC server you install the front end applications that must communicate with the (Core) back end applications. All servers and clients in the test environment are setup to use only the DNS/WINS servers in the test environment both DNS and WINS will only return the DCs in the test environment as authenticating DCs! (For DNS nothing needs to be done, but for WINS you need to delete the 1Ch record and rebuild it by issuing NBTSTAT -RR on the 2 DCs in the test environment)

DNS and WINS in the production environment and test environment are not connected in any way!

A firewall will be placed between the production environment and the test environment and the following rules:

• No traffic whatsoever is allowed initiated in the production environment to the test environment
• The WXP client and the 2 W2K3 DCs are not allowed to communicate with clients/servers in the production environment
• The SBC server is allowed to communicate with all servers in the production environment except for the NT4 DCs in the production environment

In this scenario the following is true:

• User accounts, passwords, computer accounts, groups and memberships are exactly the same in the production environment and in the test environment
• The systems and users in the test environment will use the DCs in the test environment
• The systems and users in the production environment will use the DCs in the production environment

 

To test the (core) applications, a user logs onto the WXP client, sets up a session to the SBC server and starts on of the front end apps and that app connects through the firewall to the core application server in the production environment.

 

As you may see theoretically everything seems OK and it also seems no issues should occur with this. I’m wondering:

• If such scenario will work?
• Has anyone done this before?
• What could go wrong? (assuming the firewall is well configured and the DCs in both environments cannot communicate with each other!)
• If something goes wrong, what are consequences and what is the impact?

 

I would be very interested in your opinion concerning this wild and crazy scenario, so feel free to post ANY comments!

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

(2005-11-14) It Works On Physical Hardware And It Does Not In VMware Virtualization Software

Have you ever been in the situation where you had to make a choice which Virtual Software to use for your own Infrastructure? I can imagine yes, because at this moment you can choose between a Microsoft solution and an EMC VMware solution. One of the factors that may influence your choice is support of Microsoft products within a virtual environment. If you choose Microsoft Virtual PC or Microsoft Virtual Server as your virtual solution, the Microsoft products within that virtual environment have exactly the same support as if those Microsoft products were running on physical hardware. However, if you choose one of the EMC VMware solutions (ESX server, GSX server or workstation) the support for the Microsoft products in those virtual environments is somewhat different. Microsoft explains the "how’s" and "what’s" in KBQ897615 (http://support.microsoft.com/?id=897615). Simply put Microsoft says: "if you encounter issues with Microsoft products within non-Microsoft virtualization software, Microsoft requires you to reproduce the issue independently from the non-Microsoft virtualization software". The support for all these products also depends on the support agreements you have and how you purchased those products. More can be read at "http://www.vmware.com/pdf/ms_support_statement.pdf".

Well, the main reason for me to write this here, is that I found an issues with Windows Server and Active Directory within a VM Workstation 5.0 virtual environment. I, at first did not imagine there could be an issue and always thought "it will never happen that issues might occur with Microsoft products within a VMware virtual environment whereas they will not occur on physical hardware." I proved to be wrong, as an issue occurred. I was also able to solve the issue. As everyone else I searched the internet for a solution, but did not find any. So for those that experience the same here is the problem description, its solution and my experiences!

The story goes like this…

HOW THE ENVIRONMENT SHOULD LOOK LIKE (within VMware):
* Forest Root Domain
  –> Forest Root Domain: CORP.NET (DFL and FFL = W2k3)
  –> 1 DC = GC = DNS = FSMOs (it happened with Windows Server 2003 SP1 with or without R2)
  –> Name of DC = ROOTDC01
  –> DC points only to itself as prim. Server
  –> DNS server hosts zones: CORP.NET (in domain app part), _MSDCS.CORP.NET (in forest app part), .(root) (in custom app part called ‘ROOTDNSZONE.CORP.NET’ – the only enlisted DC = ROOTDC01), 0.10.in-addr.arpa (in forest app part)
  –> All zones are AD-I and secure DDNS is enabled
  –> NO WINS used!
  –> On DNS server a delegation has been created for the zone BRANCH.CORP.NET to CHUBDC01.BRANCH.CORP.NET

* Child Domain
  –> Domain: CHILD.CORP.NET
  –> 1 DC = GC = DNS = FSMOs (it happened with Windows Server 2003 SP1 with or without R2)
  –> Name of DC = CHLDDC01
  –> DC points only to itself as prim. Server and point to ROOTDC01.CORP.NET as an alternate
  –> DNS server hosts zones: BRANCH.CORP.NET (in domain app part), _MSDCS.CORP.NET (in forest app part), 0.10.in-addr.arpa (in forest app part)
  –> All zones are AD-I and secure DDNS is enabled
  –> NO WINS used!
  –> On DNS server forwarding has been configured to ROOTDC01.CORP.NET

Before installing AD, both servers were stand alone servers and ROOTDC01 had as local password CORP and CHLDDC01 had as local password CHILD.
I installed AD on ROOTDC01 and configured everything as mentioned above. All went OK, no issues. Just for a reminder, the password for the default administrator of the forest root domain was CORP and the password for the default administrator of the stand alone server CHLDDC01 was CHILD.
Before installing AD on CHLDDC01 I did some checks:
* On ROOTDC01.CORP.NET I ran "NETDIAG /V" -> all tests passed
* On ROOTDC01.CORP.NET I ran "DCDIAG /V" -> all tests passed
* On CHLDDC01.CHILD.CORP.NET I ran "dcdiag /test:dcpromo /dnsdomain:CHILD.CORP.NET /childdomain" it said: CHLDDC01 passed test DcPromo
* Pinging between both servers is OK!
* NSLOOKUP from both servers querying different type of records works OK
* No errors in event log
* Adding CHLDDC01 to the domain CORP.NET as a member server works OK
* No firewalls used

After removing CHLDDC01 from the forest root root domain as a member server a make it a stand alone server, I tried to install AD on CHLDDC01 by configuring it as a domain controller for a new domain in an existing tree. At some point I needed to enter credentials with enough permissions to install a DC in an additional domain. So I used CORP\Administrator with the password CORP install AD on the DC. That last action failed after entering credentials and clicking OK to continue. The error presented was:

————————————-
The wizard cannot gain access to the list of domains in the forest
This condition may be caused by a DNS lookup problem. For info… blababla….
The error ‘The RPC server is unavailable’

————————————-

In short, I was not able to make whatever DC configuration I wanted to for CHLDDC01 (additional DC for existing domain, new domain, etc.) as it kept presenting me the same error over and over again…Irritating!

After a while I started thinking about the error as it was described: "The wizard cannot gain access to the list of domains in the forest. This condition may be caused by a DNS lookup problem"… but NSLOOUPs were working OK. So it had to be something like permissions or corrupt data or whatever, but not name resolution because that proved to work. Imagine a Enterprise Admin not having enough permissions to do stuff in AD. Oh, well..
 
To test permissions and credentials I created a mapping (to the ADMIN$ share) from the stand alone server to the forest root DC and used username administrator and password CORP. result = OK
To test permissions and credentials I started LDP on the stand alone server and connected to the forest root DC and used username administrator and password CORP. result = OK. I was able to anything in the directory.
To test permissions and credentials and joined the stand alone server and made it a member server of the forest root domain using the username administrator and password CORP. result = OK.
 
I logged on to the stand alone server with administrator and password CHILD, which is obvious.
I started DCPROMO to install a DC for a child domain in an existing tree and as credentials I entered the credentials of the forest root domain administrator being administrator with password CORP. NO GO!

So the name resolution tests and permission tests proved OK, and I still was not able to promote the damn thing to a DC. WTF!

Finally I decided to do a network trace, but at first I did not believe it would give any hint as name resolution was working OK and authentication was also working OK as proved by the mapping and LDP. OK, lets see what it gives…
I started the trace, started DCPROMO and after entering the credentials it gave me the error. Did the same with a custom enterprise admin I created in AD and it also gave me the error. In the output of the sniffer I saw CHLDDC01 connect to \ROOTDC01IPC$ and after that it presented the error:

————————————-
SMB (Server Message Block Protocol)
     SMB Header
          Server Component: SMB
          SMB Command: Session Setup AndX (0x73)
          NT Status: STATUS_LOGON_FAILURE (0xc000006d)        <<<<<—————–???????
————————————-
 
How could there be an auth. failure when authentication proved OK? Suddenly I changed the password from the stand alone server administrator to match the password of the forest root domain administrator. Started DCPROMO again AND IT WORKED!.

Stopped DCPROMO. Started it again and tried it with the custom enterprise admin and THAT ALSO WORKED! Changed the password for stand alone server administrator back to CHILD, started DCPROMO again and that ALSO WORKED!
 
The fun part: it never gave an access denied error, it just said that DNS was not OK! Grrr…
What I’m still trying to understand is: WHAT AND WHY? That is one I think for Microsoft and VMware to solve!
 
LESSON LEARNED: if everything else fails get that network sniffer working as soon as possible!

This issue occurred in VMware Workstation 5.0 and I have seen other posts on the internet that have a similar issue using GSX server and ESX server. However, the issue DID NOT occur on physical hardware (as those posts also mention).

 

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