Jason Lee

This post is post 4 in a series of 5 posts on ACS CheckPoint and M2Sys Biometric Scanning.

Part 1: Why Biometric?
Part 2: Why Vein Scanning?
Part 3: Installing M2sys Vein Scan Server & Configuring the Database
Part 4: Installing M2Sys BioPlugin Vein Scanning Client
Part 5: Configuring the M2sys Vein Scanning Client and ACS CheckPoint

Previously I documented our process of selecting hardware and software as well as installing the server, now I will document Installing & Configuring M2Sys Vein Scanning Client.

This part of the installation is to install the application that allows the scanner to work and talk to the database to recall a record and identify a person to the application (in our case CheckPoint).

As previously mentioned, the M2sys Vein Scanning and Fingerprint Scanning applications are two separate applications for the related technology. At the time of writing this documentation it is not possible to use a vein and finger print scanners on the same computer concurrently.  Although I have been told by M2sys that a combined solution is in development to allow both scanners to be connected to the same workstation concurrently.

Note: Most steps are identical for Fingerprint Scanning Server and DB but Vein Scanning install requires a different installer than the BioPlugin for Finger Print Scanning.
Your mileage may very depending upon your environment, do due diligence before following these procedures.

Installing M2Sys BioPlugin Client
After downloading the installer running it on a XP, Vista, or Windows 7 workstation is fairly standard.  This installer does not install the server application and the software will not work without the proper install of the server application.

Do not connect the Scanner to the computer before starting the client install process.  Connecting the hardware prior to the client install can make the device driver install significantly more difficult.

Start the installer:

 

Agree to the Licensing Agreement

 

Enter your User and Organization Names

 

Choose your Installation Location
The Default is C:\Program Files\BioPlugin\

 

Choose Install to confirm the installation configuration

 

Installation Continues without any additional user interaction

 

Click Finished when the Install is done.

 

After the installer finishes you are prompted to install the scanner

 

After you connect the scanner you may be prompted to locate the driver.

 

Hit Browse and navigate to C:\Program Files\BioPlugin\Drivers\ and locate the file HjmCap.sys
The file will be located in the Installation Destination that you choose earlier in the install process.

 

 

 

After you have located the driver the installation process is complete.

The next step is to configure the M2sys Vein Scanning Client and ACS CheckPoint.

Previous Part 3: Installing M2sys Vein Scan Server & Configuring the Database

Next Part 5: Configuring the M2sys Vein Scanning Client and ACS CheckPoint

ACS Technologies, Church IT Check In, Finger Print, Vein Scanning

Check out this web event Hosted by ACS Technologies.  Angus Davis has great insight on Volunteer and Children’s security and you should check out the web event. Register by clicking one of the options below. 

 

Note: NON-ACS Customers, when registering Enter “CITRT” as your ‘Site Number’.

                                                                                OR

Church IT ACS Technologies, CITRT

Continuation of a series of posts on ACS CheckPoint and Biometric Scanning Part 3 of 5

Part 1: Why Biometric?
Part 2: Why Vein Scanning?
Part 3: Installing M2sys Vein Scan Server & Configuring the Database

Part 4: Installing M2Sys BioPlugin Vein Scanning Client
Part 5: Configuring the M2sys Vein Scanning Client and ACS CheckPoint

As previously mentioned Part 1 & Part 2 we have deployed M2Sys’ products before and have some familiarity with the products.  Even with this familiarity there were a few areas that we had to work thru to get everything working.  Our specific install is unique since we will be deploying both Vein Scanning and Fingerprint Scanning on the same network.  At the time of writing this documentation, the two technologies are not able to be compatible with one another and require separate installation for independent use.  Future updates are expected in the next few months that will allow for one Database install and one client install to support both types of scanning on the same workstation concurrently.  Until that is the case the Vein Scanning Database and Finger Print Scanning Databases must be accessed via two separate servers.

Installation of M2Sys BioPlugIn Vein Scanning Server and Database
Note:
Most steps are identical for Fingerprint Scanning Server and DB but Vein Scanning install requires a different installer than the BioPlugin for Finger Print Scanning.
Your mileage may very depending upon your environment, do due diligence before following these procedures.

- Install OS On a new Server – Since  almost all of our servers are virtual isolation of applications is key.

- When using 2008 or 2008R2 as your server operating system disable UAC prior to starting the install of the M2Sys software.  If UAC is not disabled before install of M2sys the service will fail.
On Server 2008R2 disable UAC by going to Control Pannel>User Accounts>Change User Account Control Settings and change the slider to “Never Notify”.

- Install M2sys BioPlugin Software
Note: Installing BioPlugin 6.6.1 on a 64bit server the service will fail because the application is making a call to the Hitachi Driver which is only 32bit at this time. Uninstalling and installing 6.6.2.2 resolved this issue.

- After installation is completed you will notice a traffic light icon in the system tray

This icon only indicates if the service is running or not.  Administration of the BioPlugin is done in the control panel, not the Sys Tray icon or start menu.

Note: If you are using server 2008 or 2008r2 you will have to change the view of the Control Panel to Large or Small icons to view the BioPlugin control. BioPlugin does not display in any of the Category Groupings.

- After accessing the BioPlugin Server Preferences you will need to apply the license key.  Do this by Navigating to the last tab “"License”.  If you purchased the scanners and software from ACS Directly you will need to send your account manager the Installation ID and they will send back a License ID.  Enter the License ID and Select Apply.

- After you have installed the software and applied the license key you can restart the server and BioPlugin should show green on the little traffic signal.  It is possible for the service to try to start and fail and the green will go back to red.  This is the first indicator that we were having an issue with 6.6.1 not working  on a 64bit server.

- Check the Service is actually running by going back into the Control Panel BioPlugin Server Preferences and click on View Core Server Log.  The Log should display “Waiting for Client Request”. If the service is failing the log file will either not display “Waiting for Client” or when you click on view Core Server log nothing will happen because the log hasn’t yet been created.

Note: It is not stated anywhere in the documentation, but Cached Size: # is the number of registered users you have currently in the BioSnapOn Server.

- Once you know the service is working locally you have to decide to either keep the database on the server as an access database, which M2sys says is ok for up to 10,000 or point the M2sys server to another database server like MySQL, or MSSQL.  Because we already have a backup strategy in place for MSSQL databases and have a server running MSSQL 2008 it was best for our situation to use the MSSQL backend rather than the local access database. 
Note: In a testing environment the local database worked without any issue.

- If you are using a MSSQL database the next step is to create an empty database and user account for the BioPlugin server to use to connect to the database.  Because we already have our finger print scanning database in production we simply created a new database with the same name and added database–02 to the name.  In a dual database setup like ours it is important that the right BioPlugin server be pointing the correct database or your biometric check in with not be successful.  You define which database the BioSnapOn Server connects to in the DB string later in this process.

- After a blank database is created and the user account is set as the owner you run a script to prepare the database for use by BioPlugin.  These scripts can be found in the location on the BioPlugin server where you installed BioPlugin (Default is C:\Program Files\BioPlugin).  Copy Tables-Script-SQL Server.sql for the MS SQL install locally to the SQL Server.  Select the database for the biometrics and execute the script.  Once this is done configure your backup of the database.  After the backup configuration is done the database is ready.

-Now that the database preparation is done be sure the BioSnapon service is not running (make sure the traffic light is red) next launch the BioSnapon Server Administration tool again and Select the Microsoft SQL Server radio button on the Database Tab.  This will change the connection string to a template of a SQL connection string.

- Connecting the SQL database is a little annoying if you (like me) do not frequently work with MSSQL. But in the latest release the BioPlugin server help files give sample definitions for the connection string. You will next want to review the BioSnapOn Installation Help Guide found on the install CD in the Documentation folder.  Navigate to the Help file location: Installation>Database Configuration>SQL Server. This provides settings and options for Using ODBC connection, SA and Windows Authentication.

- We had success with  MS SQL Server DSN-Less Connection with SQL Authentication and the following connection string. Values have been changed and display what information should be entered for each variable.
  Provider=SQLOLEDB.1;
  User ID=SQL Account Created when you created the Database;
  Password=Password for the Account Created Above;
  Persist Security Info=False;Initial Catalog=Database Name for the Database you created above;
  Data Source=Name of the SQL Server to which you are connecting

- Apply the settings and restart the server.  After the restart your BioPlugin server should have a green light and the core server log should be ‘waiting for client request’

Now you are ready to Install and configuring the BioSnapOn Client on the workstation, point it to the BioSnapOn Server and testing scans.

Previous -  Part 2: Why Vein Scanning?

Next – Part 4: Configuring M2Sys Vein Scanning Client

ACS Technologies, Church IT Check In, Finger Print, Vein Scanning

Part 2 of 5

Part 1: Why Biometric?
Part 2: Why Vein Scanning?
Part 3: Installing M2sys Vein Scan Server & Configuring the Database

Part 4: Installing M2Sys BioPlugin Vein Scanning Client

Part 5: Configuring the M2sys Vein Scanning Client and ACS CheckPoint

In the past year we have learned a lot about biometrics and our check-in system and I have had people ask me multiple times a great question, “Would you do it again?”.  They are really asking would we use finger print scanners as an key component of our check-in system, and I would reply, Yes.  The finger print scanning has been successful to accomplish the two areas we saw concern in the other flavors (bar code, key fob, number/name lookup) of check-in: Security and Speed.  The finger scanning has allowed us to have check-in remain secure, limiting the use to families who had followed the registration process and allow them to do it in a process that takes less than 15 seconds per family.  A major positive of the finger scanning over other scanning solutions, the speed isn’t dependant upon the end user remembering to bring a key tag or key fob with them to church.

Even saying Yes to that question wouldn’t mean we haven’t learned things over the past year and we haven’t modified the configuration. We have learned that finger print scanning is dependant upon indoor and outdoor temperatures, humidity, dry skin, etc.  The quality of the scan is affected by more environmental variables than we expected.  A second learning point was paying attention to the scans captured at pre-registration.  This process is much more important than we originally thought.  If attention to detail was paid at the pre-registration process then the success rate increased exponentially.  And finally, we were affirmed in our thought that there would be some people not able to use the biometric system because they just didn’t have “good” fingerprints.  So with the environmental variables and the fact that some people couldn’t use the biometrics we had to identify a workaround, which was allowing people to check-in by pager number. This is not the security number printed on the child’s tag but rather the number that is used to alert families the DLand staff need them to come get their child.  Allowing check-in via pager this did have negative impact on speed and people do forget their number.

So when it was time to start planning our rollout of Jr. High and Sr. High check-in we decided to put all options back on the table.  Our team came to the conclusion that if we could make finger scanning more reliable it was still the best option.  This planning was happening concurrently to the release of a new product by M2Sys called Vein Scanning.

Vein Scanning works under the principal that your vein alignment in your fingers is as unique as your finger prints.  Allowing you to be identified in a system without the environmental and “good” print concerns noted above.  The Scanner uses infrared to ‘see’ your vein alignment in your finger and allows the software to translate that alignment into a string of numbers that can be called back to identify you after you have pre-registered.

The solution sounded good but needed to be tested.  We contacted ACS and asked if we could put the scanner thru some testing and they provided a demo for us.  Our testing showed the Vein scanners to be much higher in accuracy no matter the variables.

So why not vein scanning in the first launch a year ago?  The products weren’t available a year ago in the capacity they are now.

Will you be migrating your finger print users to vein scan users?  Not at this time, currently the two technologies are not able to be used concurrently on the same workstation and would require a mass re-registration process for over 1250 individuals.

Will you possibly migrate everyone to vein scanning?  Once the converged product allowing both types of scanning at one workstation (12 weeks) we might explore this option.

Previous Part 1: Why Biometric?
Next Part 3: Installing M2sys Vein Scan Server & Configuring the Database

ACS Technologies, Church IT Check In, Finger Print, Vein Scanning

Recently several new initiatives have caused us to look into extending our Phone system beyond the physical location of our main campus.  We have an Avaya IP Office 412 with 150+ digital extensions.  As part of the IPO you can do VOIP extensions but we haven’t had a large need to deploy those since our building was already wired for a phone and data network separately (Major PROS & CONS to this but not in this post). 

We do have however a couple handsets in locations where we can’t get a pair of copper for the digital phones so we have  a couple VOIP extensions on campus.  Those have worked great, plug the phone into the network, configure the IP and the VLan and your making calls.  So it should be that easy over our VPN right?  Wrong. 

After several hours of searching to figure out the issue we learned it was both a IPO Issue as well as a configuration issue in the Sonicwall Firewalls.  Since there was little documentation about this specific combo I have documented it here as well as the nuggets of info we learned along the way.

Hardware Used:
- IPOffice 412
- Avaya 5610sw IP-Handset
- Sonicwall TZ100 at remote location and Sonicwall EClass 5500 on main campus.

Process:

- Configure a new IP Extension on the IPO, Enter Only the Extension ID and Base Extension
- Configure the User for the Extension and Program Buttons Etc.
- Create an Incoming call route for the DID
- Connect the 5610 to the local network to make sure the phone is working locally. 
- Boot From DCHP, Enter IPO IP address (Phone Server) and Enter Voicemail Server IP (FIle Server)
- After the phone talks to the IPO it updates Firmware updates and the the phone is functional

At this point all was well and we were able to make and receive calls from the IP handset and it was time to take the phone to the remote site.  The remote site is where we started having connectivity issues and the phone wouldn’t boot completely.

-Plug in the phone and choose DHCP and it fails to connect to the server.  Do  a phone reset to clear out all networking gremlins from local network settings: Press Hold then 25327#
-Phone reboots and grabs DHCP address but cannot talk to the TFTP server.
Note: Workstation running the IPO Manager software runs a TFTP server when the application is open but not editing a config file.  If Manager isn’t running IP Phones will not update.

In the troubleshooting we could ping any device on the core network from the VPN except the IPO.  You could ping the Voicemail Server but no response from the IPO.  This was because the IPO requires you to  manually add an IP route for each subnet that is not the subnet of the IPO’s LAN1 Interface.

Some discussion forums noted that you would have to have a license for VPN or Remote IP Handsets but that is not the case.
To Configure the IP Route in the IPO:
- Open the IPO Config Manager and navigate in the tree to: IP Route
- Right Click and Choose New.
- In the new Route Config enter the IP Address of the Remote Router, IP Mask of the Remote Location
- The Gateway IP address should be the LOCAL IP of the Gateway on the Local network
  (Don’t enter the Gateway IP that you entered above in the IP Phone)
- Choose the Destination of LAN1
- Save and Merge the Config. (Values shown have been modified and will not work with live config)

After this we should have seen the IP Handset boot, talk to the TFTP server and then work…. but that wasn’t the case.  When the phone would boot it would not show up as an extension in the IPO System Status nor would it check in with the TFTP server.  It would however appear to have booted and have a base extension without any call appearances.  Trying to use the phone resulted in a bunch of beeps.

After we were finally ready with the IPO configuration it now appeared something was blocking traffic over the VPN link from the remote location to the main campus. 

A call to Sonicwall reveled that in the latest firmware 5.5.x there are default settings enabled that should not be enabled to allow H.323 packets to travel from remote to local sites over VPN.  These settings should be enabled if you are NATing VOIP traffic via the WAN but not enabled if your VOIP traffic is traversing via VPN.
(Leads me to ask the question, can you not have a combination of VOIP Over VPN and VOIP via NAT, but that question can remain unanswered since it doesn’t impact us).
To disable these settings in the Sonicwall Admin interface go to VOIP and the ALL of the following should all be DISABLED on BOTH routers (Local and Remote).
- Enable Consistent NAT
- Enable SIP Transforms
- Enable H.323
It is important to note these setting changes require a reboot of both routers to take effect.

After a reboot of both routers and a reboot of the handset it registers with IPO as an extension and calls can be made and received.

It is important to note, this VOIP extension is not in the same physical location and it is the PBX operators responsibility to notify your dial tone provider of the physical location of that handset for E911 (PS/ALI Compliance).

Church IT 5610, Avaya, IPOffice, VPN

 

In the process of migrating our servers from 2003 to 2008 and 2008 R2 we have started migrating our print server.  When you bring online the print server we downloaded the 32bit and 64bit drivers for each printer.  While most of our systems are still 32bit the new print server is a 64bit server, hence needing both drivers.

Installing the 64bit drivers was fairly straight forward but allowing 32bit machines to print via this server you also have to add the 32bit drivers as well.  In the past this has been the reverse but the process is the same.. Add and Share the printer then go back in to the Printer Properties and on the Sharing tab add the driver for the other, in our case adding the 32bit drivers for the guests.

When adding the 32bit drivers we ran into some issues.  Since a lot more printer drivers are shipping with windows in 2008 Server the wizard that adds the printer wants to install the OEM driver.  Which we found would print just fine from the server but give us one of two errors when we tried to add the 32bit driver.

The first 32bit driver error:

This error is a result from attempting to install a 32bit driver that doesn’t match the 64bit driver that the printer is currently using.  This is most likely caused by installing the printer with the OEM driver for that printer that came from windows update or shipped with Windows Server.  This is an issue because the Printer name in the OEM.inf and the .inf file provided by the vendor for the 32bit driver is somehow formatted differently … ie: ‘PCL_6’ might be ‘PCL6’ or some other slight variation in the printer name in the .inf file. 

The two solutions are to:

1. Find the oemsetup.inf file and edit the printer name or change the 64bit driver that the printer is using. 
2. The easier of the solutions is to change the 64bit driver from the OEM driver to a downloaded 64bit driver supplied from the vendor.  Once you change the driver or add the manufacture’s driver the install of the x86 driver will not be an issue.

The second 32bit Driver Error:

 

This occurs when the driver doesn’t match the formatting in the 64bit driver as above, but the issue isn’t resolved when using a vendor supplied 64bit driver.  You can attempt to find the differences between the two vendor supplied drivers as mentioned in issue 1 or take the following steps to install the 32bit driver.

1. Login as an Admin on any  client machine running 32-bit OS (it can be W2k3, XP, Vista doesn’t matter)
2. Access the print server \\PrintserverName\ and choose Printers and Faxes
3. Select the printer you would like to add the 32-bit driver
4. Go to properties
5. Sharing Tab
6. Additional drivers
7.Check the box for x86 for windows 2000,windows xp and windows 2003
8.click ok
9. The driver will be installed from the included drivers on the 32bit OS or it will prompt you for the location of the driver. 
8.Once the driver is installed you can check the server and the X86 box will be enabled.

Church IT 2008r2 Print Server

Previously I documented the process for installing ACS’ Facility Scheduler Application on a 2003 Terminal Server as noted [Here].  But now its time to upgrade our ACS Remote Desktop Server to 2008r2 and the process for installing FS is a little different.  So here were our steps, your mileage may vary.

1. Download the latest installer from the ACS Client Portal. 
    (note the version released on 8/28/09 requires the .Net Framework 3.5)

2. .NET3.5 is included in 2008r2 but when you start the ACS FS installer you get the error displayed below. 

 

The next logical step would be to install .Net Framework, but remember it comes with Server2008r2, so you can’t just install it as the error below notes.  Rather you have to enable it not install.

 

The error notes to use the Roles Management tool, which you might think is Adding or Removing Roles, but what the error message really means is to go to the Server Manager then the Features item in the display tree then and then select add Feature to enable .Net 3.5.1. 
(Note: You can deselect the option to install WCF Activation which then won’t require you to install IIS on this server when you enable .Net 3.5.)

 

3.  After you have enabled .NET Framework 3.5.1 you can run the ACS Facility Scheduler installer.
4. Once the installer is complete launch the application and enter your site number
5. You may be prompted to download application updates, if prompted choose yes to update.
6. Once the updates are complete you should be able to login to FS with your login.
7. After updating and successfully launching the software you need to copy the application files to the default user’s folder so all users will be able to run the application on the Remote Desktop Server.  You can do this by the following steps:

• Enable Hidden Folders by Clicking on Organize>Folder and Search Options> View Tab and then Select Show Hidden Files
• Browse to C:\Users\%User%\AppData\Loca\
• where %User% is the name of the account that was logged in when you installed FS
• Copy the ‘ACS Technologies’ Folder
• Paste the Copied ‘ACS Technologies’ Folder in C:\Users\Default\Appdata\Local\
• To place a shortcut on the Remote Desktop Server desktop for all users, go to c:\Users\%User%\Desktop and Cut the ACS Facility Scheduler shortcut, and paste it in c:\users\Public\Public Desktop\

8. Test your work by RDPing into the server (with an account that hasn’t logged into the server or the profile has been deleted) and you should be able to launch Facility Scheduler and access the application.

• If ACS pushes out updates between the time you do the original install and the first time the user is logging in they may be prompted on the first use to update the application, if so choose yes and let the application update and then launch.

 

Happy Facility Scheduling…

ACS Technologies, Church IT ACS Technologies, Facility Scheduler

One of our recent projects has been preparing for and testing of the migration of our ACS Server.  We are are working to migrate our ACS Terminal Server from a 2003 Terminal server to a 2008r2 Remote Desktop Server and one of the problems that has caused frustration is the Remote Desktop Server CALs (Client Access Licenses).

We have software assurance so having those CALs wasn’t the issue, SA migrated our 2003 TS CALs to 2008r2 Remote Desktop CALs… The problems started when we brought the new server online and added the Remote Desktop Role it wouldn’t sync up with the license server. 

Previously we had setup one of our ‘backup’ domain controllers to be the terminal server license server so all Terminal servers would auto discover our Terminal Server licenses… but not with this new 2008r2 box.  Well alas I found out why… as noted here in the RD Licensing Tech net article:

“Prior to Windows Server 2008 R2, the license server was automatically discovered on the network. This discovery is no longer supported for an RD Session Host server that is running Windows Server 2008 R2.

In Remote Desktop Session Host Configuration in Windows Server 2008 R2, you must specify a license server for the RD Session Host server to use. You can either choose from a list of known license servers or manually enter the name.”

But nowhere in the document does it say how do setup said configuration… Other than you can do so by going to the Remote Desktop Session Host Configuration window.  In the RDSHC window (my abbreviation not Microsoft’s) you can see what license issues you have, and in our case we didn’t have an active license server but we couldn’t figure out how to fix that.

Finally today I came across this article [here] which links to this article [here] that actually gives the step by step instructions.  The gotcha is in the RDSHC window you need to not right click on any of the tree headings but select the top level and then go into the window and right click on the RD license server text for the properties menu to display. 

Incase the links go dark here are the step-by-step copied from the TechNet page.

To specify a license server for the RD Session Host server to use

1. On the RD Session Host server, open Remote Desktop Session Host Configuration. To open Remote Desktop Session Host Configuration, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.

2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

3. In the Edit settings area, under Licensing, double-click Remote Desktop license servers.

4. On the Licensing tab of the Properties dialog box, click Add.

5. In the Add License Server dialog box, select a license server from the list of known license servers, and then click Add. If the license server that you want to add is not listed, in the License server name or IP address box, type the name or IP address of the license server that you want to add, and then click Add.

   You can add more than one license server for the RD Session Host server to use. The RD Session Host server will contact the license servers in the order in which they appear in the Specified license servers box.

6. Click OK to close the Add License Server dialog box, and then click OK to save your changes to the licensing settings.

You can also specify a license server for the RD Session Host server to use by applying the Use the specified Remote Desktop license servers Group Policy setting. This Group Policy setting is located in Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Licensing and can be configured by using either the Local Group Policy Editor or the Group Policy Management Console (GPMC). Note that the Group Policy setting will take precedence over the license servers configured in Remote Desktop Session Host Configuration.

Now.. I have to say I am not complaining that the new navigation is bad.. just the new way things are being displayed in 2008 and 2008r2 one has to get accustomed to… BUT i am complaining that its a little frustrating when you search the net for ‘how to configure type articles’ and you have go to three or four layers deep to find the instructions.

So… i hope this helps you in you quest to configure the Remote Desktop license server… as well as provides me a place to look when I forget next time I bring online a new server.

Church IT Remote Desktop Server Licensing, Terminal Server 2008r2

In my previous post [here] I documented how to enable Access Based Enumeration on a 2003R2 DFS AD Namespace.  Since then several times in testing and now once in production or NameSpace has become orphaned from its NameSpace Server Host and I have had search how to clean-up an orphaned DFS Namspace.

Incase it every happens again… and so that I don’t have to search the web and try to figure out which random terms I used in the Google search I am documenting the process to fix an Orphaned Namespace here… for your use as well as mine. 

Since historically just pasting the links ends up burning me… I have included the step by step procedure, that was of course copied from several websites (Note: I am not claiming, any responsibility for, or noting the existence of, original content).

Your Mileage may very and no implied guarantees that the following steps will solve your issue… But the following did fix my issue with an Orphaned Namespace.

These steps have worked to delete the orphaned namespace because of server failure or loss of DFSRoots directory
(or migrating from one SAN to another and thinking that DFS replication will replicate your DFSRoots to a new volume on the new SAN… which by the way DFS replication doesn’t replicate DFSRoots)

 

The domain-based DFS configuration is stored in the AD database as well as some settings on the DFS Namespace Host server, so every time you launch the DFS management console, it will try to retrieve the DFS information from AD.

There are two nodes in AD which store the information of the DFS Namespace:

Node1. Store the DFS Namespace information which shows under the Namespaces node in DFS management console. CN=DFS-Configuration, CN=System, DC=Domainname, DC=domainsuffix

Node2. Store the DFS Replication group information which shows under the Replication node in DFS management console. CN=DFSR-GlobalSettings, CN= System, DC=Domainname, DC=domainsuffix

ON a DC use ADSIedit.msc to delete the orphaned namespace information \\domain.tld\DFS_Namespace under the node CN=DFS-Configuration.

1. Launch ADSIedit.msc

2. Connect to "Default naming context" (the domain partition)

3. Expand and locate to the following node:
CN=Dfs-Configuration, CN=System, DC=ourdomain, DC=tld

4. Check if the orphaned namespace CN=DFS_Test is under it, if so, you may delete this node CN=DFS_Test

5. Afterwards, please run "repadmin /syncall" if there are multiple domain controllers in the environment

6. Then run "dfsrdiag pollad" on all the DFS member servers to manually make them sync the information from AD database.

Then, you may launch the DFS management console and then right-click on the orphaned namespace, and then select Remove Namespace from Display… if needed.

After these steps you can proceed to re-create your DFS Namespace. When creating the Namespace you may receive the error: “ The Server you specified already hosts a namespace with this name. Please Select Another Namespace or another server to host the namespace.”

If that occurs:

1. Stop the DFS service by tying net stop dfs at a command prompt.

2. Delete the following three registry keys/values:
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Domain\YourOldNamespace
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\YourOldNamespaceShare
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\YourOldNamespaceShare

3. Reboot the server and restart DFS Service.

4. If it still appears, delete the Namespace from the Display.

5. Proceed to recreate a Namespace.

Church IT DFS NameSpace

As I have discussed in previous posts  [1] , [2] and [3] we would love for synchronization or sharing of data between our ChMS and Planning Center Online.  My recent push has been to get the sync to work for ACS and PCO, obviously because that would impact us most because we use ACS. 

In our conversations with PCO Owner Jeff Berg we found out that PCO had plans to synchronize with multiple ChMS products not just ACS, which was great.  In that conversation multiple staff from ACS talked thru how to make the APIs work and for PCO to integrate. It looked like we finally had progress to an integrated solution not just for ACS but all Church Management systems.

Then turn the page a couple months later, and this week I was disappointed to receive the email below, which I totally can understand but disappointed none the less.

Hey Jason,

I just wanted to let you know that we have decided to kill our "SharpSync" project for now. We have been working on it for over a year and just have not seen any fruit from it. The complexities of working with different schemas & APIs are too big of a hurdle for our small team to attack…

 

We have had a long discussion this morning about integration and the difficulties in what we were trying to accomplish. We have found this too large of a task for us to accomplish.  This is not just with ACS but with all of the other ChMSs we were talking to. We have spent over a year and a lot of cash doing this and just haven’t found a reliable way to integrate with all of the ChMS systems out there.  Every time we thought we were clear we would run into a hurdle with an API or data consistency issue.

We have discussed this with some other ChMSs and some have decided to integrate from their end…

I’m really sorry for this, I was very excited for this project but it just didn’t work.

Thanks!

Jeff

So if you who have asked about such a tool, I encourage you to contact your ChMS and see if there is a way to make this project work.  If you are an ACS customer contact Sally Grantham and let her know your needs and interests.

I will stay to the PCO crew, thanks for the effort, and I still hope that we can see this product work.

Church IT ACS Technologies, Planning Center Online