Autumn 2012: CC4 TEN: Before, during and after · Autumn 2012: CC4 TEN: Before, during and after David Wright [email protected] | @rmdavidwright

Autumn 2012: CC4 TEN: Before, during and after

David Wright

[email protected] | @rmdavidwright

RM Technical Seminars autumn 2012 CC4 TEN: Before, during and after

www.rm.com/techseminars ©2012 RM Education Page 2

Introduction CC4 Tools for Existing Networks allows you to phase your introduction of the Community Connect 4 management toolset in to your school. Whether you have a stand-alone Microsoft Windows network, or a network currently managed by Community Connect 3 (CC3), CC4 TEN allows you to gradually move to the new tools if that suits your school better. Before the Community Connect 4 management server is added to your existing network there are a series of network checks that need to be carried out in order for the commissioning to be as smooth as possible. In this paper we will take a look at these pre-commissioning checks so you can carry out a ‘pre-pre-commissioning checks’. Once the Community Connect 4 management toolset is added to your network, there will be a phase where you have a ‘hybrid’ network. In this paper we will take you through the steps to moving the users, computers and applications over so they can be managed and controlled through the Community Connect 4 management toolset. If you have Community Connect 3 today, once you have completed the work in the hybrid phase, CC3 can be decommissioned. We will take you through what happens at this point. A gentle reminder If you have Community Connect 3 then moving to a next generation network management platform should be a high priority. Community Connect 3 supports the use of Windows 2000 Server and Windows Server 2003 for your servers and Microsoft Windows XP Professional for your clients. Microsoft has already ended support for Windows 2000 Server and will end support for Microsoft Windows Server 2003 in July 2015. Support for Microsoft Windows XP Professional ends in July 2014. This means, that after these dates, Microsoft will no longer be issuing security updates for these products that could potentially leave your network vulnerable. Additionally, it is likely products such as backup and anti-virus solutions won’t support these operating systems, increasing the risk of network downtime. In short, you may only have six weeks left to move your network if you plan on doing this over the summer break!



The steps to moving to the Community Connect 4 management tools There are several steps to moving your network from your current network management toolset over to the Community Connect 4 ones. These can be summarised as:

1. A network pre-installation check to make sure there aren’t any problems on the network before we add the Community Connect 4 management server and any User Storage Servers, (a User Storage Server is a Windows 2008R2 member server which can be used to store user profiles and home folders).

2. Installation of the Community Connect 4 management server and User Storage Servers.

3. Configuring and migrating user data from your existing management toolset to the Community Connect 4 toolset.

4. If you have Community Connect 3 servers at the moment, once everything has been migrated, the final step is to decommission the Community Connect 3 servers.

We will examine these steps in this paper. Before starting the checks Before you start checking your network before the installation of the Community Connect 4 management server goes as smoothly as possible, with very little remedial work required before the management server can be commissioned, you may need to make some changes to your existing network, either yourself or with the help of your support provider. Before any changes are made it is vitally important you have a good, working backup of your domain controllers. Before you make any changes check that your backup is good and working, (i.e. you can restore files from it). If the backup isn’t working as it is expected to you should fix this issue before proceeding. Later in this paper we will look at installing third party software that is required on the domain controllers. This software may require a restart of the domain controllers so schedule this for a time when it is convenient to restart your servers. The network pre-installation check



We want the commissioning of the Community Connect 4 management to be as smooth as possible and for you to start using the management tools straight away, that’s why before we add your Community Connect 4 management server we carry out a pre-installation health check. This allows us to make sure there aren’t going to be any problems during, or after, the installation. It may be a good idea for you to run the checks you can do prior to the pre-installation check so that, when we carry it out, there aren’t any problems that you then have to correct. Regardless of whether your current network is using the stand-alone Windows tools, or Community Connect 3, running through these checks is recommended. These checks are the same as the ones we will carry out. When we carry out the checks, if we find a problem we will log a support call, (if you are supported by RM). When running through these checks, if you find a problem it would be worthwhile investigating the problem and rectifying it before the pre-installation check is carried out by RM.

Up to date version of Windows server operating system. If you have a Community Connect 3 network, it should have Service Release 6 installed. This includes Windows Server 2003 SP2. Should your Forest Root Domain Controller be Windows 2000, then this should also have Service Release 6 installed on it. You can use Version Reporter on your server to make sure that Service Release 6 is installed. If your network is currently stand-alone then you need to make sure it has at least Windows Server 2003 Service Pack 2 installed. You can check this at the server by following these steps:

1. Log on to the server as an Administrator user.

2. From the Start Menu, choose Run.

3. In the Run dialog box, type winver and press enter. The About Windows dialog box details the version and service pack of Windows installed.

Domain Controller server time check Time is very important on a Windows network. Community Connect 3 Forest Root domain controllers are configured to synchronise their clock with a timeserver. However we have seen in the past servers not being able to connect to this server due to the port the time service uses, (Port 123), being blocked broadband providers. As part of the pre-installation health check we



make sure that the date and time are correct on the domain controllers in the current network. If there is a time difference between your forest root domain controller, replica servers and clients you may already be seeing issues on your network such as Active Directory® failures and group policy objects not being processed. Should the time be wrong on your network, it may be worth checking that your Forest Root domain controller can connect to a time service. You can do this by opening a command prompt and entering: net time /querysntp If your forest root domain controller can connect to the timeserver it has been configured to synchronise its clock with it will display the following:

If it is unable to, and you are confident you have a connection to the Internet then you need to speak to your broadband service provider, as it may be the port that time service uses, (port 123), is blocked and needs to be opened. Replica and member servers, and Community Connect 3 workstations are configured to synchronise their clocks with the forest root domain controller in the domain. If you have a stand-alone Windows network that is configured as per Microsoft’s recommendations, it is likely that they connect to the domain controller that is the authoritative timeserver in the domain. Group Policy Object check (Stand-alone Windows only) Community Connect 4 includes Group Policy Objects that are applied when a computer starts up or a user logs in to a Community Connect 4 managed computer. Group Policy Object names must be unique so it is important that, before the Community Connect 4 management server is added to the domain, and the CC4 Group Policy Objects added, that there aren’t any existing GPO’s with the same name as the ones that will be added. You can compare the names of the Group Policy Objects that already exist by using the Group Policy Management Console in Windows Server and producing a report that lists all of the existing GPOs. To run this report, follow these steps:



1. From the Start menu, choose All Programs, Administrative Tools, Group Policy Management.

2. In the left-hand pane of the Group Policy Management Console, expand Group Policy Management, Forest: , and Group Policy Objects.

Compare the list of Group Policy Objects in the right-hand pane with the following list to make sure none of them have the same name as GPO’s that will be added when the Community Connect 4 Management Server is added:

• Accessibility • RM Explorer UserType • All stations • RM Member Server • All Users • RM Workstation • Build Security • Script Actions • CyberCafe StationType • Shared Desktop StationType • Internet & Email • Shared Laptop StationType • Internet Disabled • Software Restrictions • Logon Configuration • Staff UserType • Management Console • Standard UserType • Personal StationType • System Admin UserType • RM Domain Controller • Terminal Servers StationType

If there are any Group Policy Objects currently which have the same name as any of the Community Connect 4 ones then they should be renamed to make them unique. Microsoft has produced a knowledge base article that describes how to rename a Group Policy Object. This can be found by clicking on the following link:

http://technet.microsoft.com/en-us/library/bb964274.aspx Domain Naming System checks The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates information with domain names assigned to each of the participating entities. In the Spring 2010 round we presented a session called ‘DNS: How it works’. If you would like an in-depth explanation of what DNS is and how it works then these notes can be downloaded from the RM Knowledge Library at: http://www.rm.com/support and searching for the article DWN1646107.



There are several checks you should make to ensure the DNS on your current network is configured correctly and working as you would expect ready for the addition on a Community Connect 4 management server.

DNS Interface check Each of the domain controller’s network interface cards should be configured so that they only use the local installation of DNS on that server. To check that the network cards are configured to use DNS correctly:

1. On each Domain Controller that is part of your network, log on as a System Administrator.

2. From the Start menu, choose Run and type: dnsmgmt.msc

3. Right-click on the server name in the left-hand pane and choose Properties. On the Interfaces tab make sure that ‘Only the following IP addresses’ is configured with the IP address of the Domain Controller you are checking this on. If it isn’t then change the IP address so it is the IP address for that Domain Controller.

4. Click on OK to save the changes.

5. Leave DNS Management open ready for the next set of checks we need to make.



DNS Forwarder Checks DNS on your network is configured so it can easily and quickly resolve the IP addresses of the servers, computers and other equipment that uses IP addresses to its domain name. There will be times when the local DNS installation is unable to resolve a domain name to an IP address, or vice-versa. The best example of this is when the Internet is being used. When the network needs to access a resource that is connected to the network it needs to be able to access it via its IP address. An example of this is when a user prints to a network printer. The network printer will have an IP address however it is often referred to by its share name. In order for the print job to be sent to the printer then its share name needs to be resolved to its IP address – this is the job of your local DNS installation. If they are accessing the Internet however, and type www.rm.com in to the browser’s address bar, then this still needs to be resolved to an IP address but your local DNS installation can’t resolve this. In effect, it doesn’t know what www.rm.com resolves to. Rather than displaying an error, it forwards the details on to another DNS server – in the case of web addresses, a DNS server on the Internet. The local DNS installation needs to know which DNS server to forward queries to and we need to check this is set up correctly on every DNS server, (or Domain Controllers), on your network so that these can be resolved correctly. In DNS Management on your first Domain Controller:

1. Right-click on the domain controller’s name and choose Properties.

2. Click on the Forwarders tab. Check that the Forwarders are configured with the IP address of your broadband service provider.

3. Once you have checked, or updated these details, click OK to save the changes.

4. Repeat these steps on all the Domain Controllers.

5. Leave DNS Management open.



Preferred DNS Server Check When a domain name needs resolving to an IP address, (or vice versa), it goes through a routine of checking DNS servers to see if it can resolve it. First of all, it will check its preferred DNS server, which is configured through the DNS Server. If the preferred DNS server cannot resolve it, it will fallback to its alternative DNS server. If the alternative doesn’t know, it will then go to an external DNS server. If we use the example of an Internet domain name, when the user types the friendly name in, it will attempt to resolve it against the local, preferred DNS server. If that can’t resolve it, (and it’s unlikely it can), it will attempt to resolve it against its alternative DNS server, which is likely to also be local if there is more than one Domain Controller in the network. If the alternative DNS server doesn’t know it would then go outside the network to resolve it, (hence the forwarder check you looked at earlier.). To check that the Preferred DNS server settings are correct, then:

1. Open a command prompt on the server.

2. At the prompt, type in: ipconfig /all



3. Check that there isn’t any public DNS IP addresses in the results that are displayed.

If there are any public IP addresses listed then these need to be changed on the properties of the network card on the domain controllers:

4. From the Start menu, choose Control Panel, Network Connections and then select Local Area Connection.

5. In the Local Area Connection dialog box, click on the Properties

6. On the Networking tab, select ‘Internet Protocol version 4 (TCP/IPv4) and click the Properties button.

7. In the DNS Servers entry, enter the IP address of the forest root domain controller as the preferred server, and the IP address of this server, (it is a replica domain controller), as the alternative DNS server.

8. Click OK to save the changes.

9. Repeat these steps on the other domain controllers that are part of the network.



DNS Forward Lookup Zone checks DNS, essentially, is broken down in to two parts:

• Forward lookup zones • Reverse lookup zones

Forward lookup zones are used to resolve domain names, (or friendly names) to IP addresses. When you attempt to access a resource on the network, for example a network printer, the share name of the printer needs to be resolved to its IP address. This is the job of the forward lookup zone of DNS. Reverse lookup zones do the reverse – they resolve IP addresses to their domain name. The next set of checks makes sure that DNS forward and reverse lookup zones are configured on all of the domain controllers that are part of the network. We also need to check that these zones are integrated in to Active Directory. Integrated DNS enables Active Directory storage and replication of DNS zone databases. From Windows 2000 Server, Active Directory accommodates storing zone data. When a server is configured as a domain controller with a DNS server, zones are usually stored as text files on name servers — that is, all of the zones required by DNS are stored in a text file on the server. These text files must be synchronized among DNS servers by using a system that requires a separate replication topology and schedule called a zone transfer. However, if you use Active Directory–integrated DNS when you configure a domain controller as a DNS name server, zone data is stored as an Active Directory object and is replicated as part of domain replication.

1. In DNS Management, which you opened earlier, expand the name of the server in the left-hand pane and expand Forward Lookup



Zone.

2. Beneath the Forward Lookup Zone there will be subzones for at least the network domain name, (for example schoolname.internal), and a zone called Local. Right-click on each sub-zone and choose Properties. In the dialog box ensure that the type is set to ‘Active Directory-integrated’.

3. Click OK to close the Properties dialog box.

4. Expand Reverse Lookup Zone in the left-hand pane and ensure there is a Reverse Forward lookup zone configured for the domain IP range.

5. Expand Reverse Lookup Zones and right-click on the domain IP, choosing Properties from the sub-menu.

6. In the Properties dialog box, ensure that the type is set to ‘Active Directory-integrated’.



7. Click OK to close the Properties dialog box.

8. Repeat these steps on all your Domain Controllers.

If your network doesn’t use Active Directory integrated DNS then this will need to be configured prior to the Community Connect 4 management server being added to the network.

DNS Scavenging check On a Windows Server network, when a resource registers with DHCP, DNS is updated with the details of the device. This is useful because it means the network support team don’t have to manually add DNS entries for every network device that exists on the network. A potential downside to this is that the DNS records can quickly become full of out-of-date information. For example, if a user brought a device in to your establishment and connected it to your network, it would be issued with an IP address and DNS would get updated with the details of the device. If that device never connected to the network again, DNS would continue to hold that information about that device. Of course, if DHCP is configured correctly, (and we will look at this later on in this paper), then eventually the IP address issued to this device would be released and could be issued to another device and consequently a new DNS record would be issued for the device. DNS Scavenging is designed to clear out of date, (known as stale), records. There are two places this should be set:

1. On the server’s properties.

2. On the Forward lookup zones. To check and configure the scavenging settings, in DNS Manager, follow these steps:



1. In the left-hand pane, right-click on the server and choose ‘Set

Aging/Scavenging for All Zones …’.

2. There should be a tick in ‘Scavenge stale resource records’. If there isn’t, place a tick in it.

3. In the ‘Refresh interval’ section of the dialog box, make sure Refresh is set to 7 days.

4. Click the OK button, and when prompted, ensure ‘Apply these changes to the existing Active Directory-integrated zones’ is ticked and click OK.

5. In the left-hand pane of DNS Manager, expand Server and Forward Lookup Zones so the network domain is displayed.

6. Right-click on the domain and choose Properties.

7. On the General tab, click the Aging button.

8. The Ageing/Scavenging properties will be displayed. Check that the ‘Scavenge stale resource records’ box is ticked and the refresh rate is set to 7 days.



9. Click OK to save these changes and click OK to return to the main DNS Manager window.

10. Follow steps 1-4 again to make sure the changes you have just made have been applied.

11. Repeat these steps on each of your Domain Controllers.

Once completed, any DNS records that are older than one week, (seven days), will be deleted if they haven’t been accessed in that time.

DNS Server record check DNS contains special entries for the domain controllers on the network. These records are known as service records and they allow network resources, such as LDAP and Kerberos services to be used. LDAP stands for Lightweight Directory Access Control and it’s an application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. In other words, LDAP is used to access Active Directory. Kerberos is a computer network authentication protocol that works on the basis of "tickets" to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Service records in DNS allow ‘the network’ to locate servers which support LDAP and Kerberos and before adding a Community Connect 4 management server, these records should be checked in DNS manager to make sure the information is correct and up to date.

1. In DNS manager, in the left-hand pane, expand the server and expand Forward Lookup Zones.

2. Expand , _msdcs, dc, sites, %sitename% _tcp and check there is a _ldap and _kerberos record for all the domain controllers that are currently part of the network.



3. Expand _msdcs, gc, sites, , _tcp and check there is a _ldap record for all the domain controllers that are currently part of the network.

4. Expand _msdcs, gc and check there is an A (host) record for all the domain controllers that are part of the network.

5. Expand _msdcs, gc, sites, %site name%, _tcp and check there is a _ldap record for all the domain controllers that are part of the network.



6. Expand, _msdcs, _pdc, _tcp and check there is a _ldap record for the domain controller on the network that holds the PDC emulator role on the network.

If this is a Community Connect 3 network, typically this server will be forest root domain controller. If this is a stand-alone network then again, this is usually the forest root domain controller. If you are unsure you can check which server holds this role by opening a command prompt and typing: dsquery server -‐hasfsmo pdc

This will return the name of the server holding the PDC Emulator role. You can check this is the same as the ping e.g.:



ping CC3-‐SR-‐001

7. Expand _sites, , _tcp and check there is a _gc, _ldap and a _kerberos record for all the domain controllers on the network.

8. Expand _tcp

9. Check there is a _gc record for all the domain controllers, a _ldap record, _kpasswd record and a _kerberos record for all the domain controllers that are part of the network.

10. Expand _udp

11. Check there is a _kpasswd record for all the domain controllers and a _kerberos record for all the domain controllers that are part of the network.



12. Repeat these steps for all the domain controllers that are part of the network.

Cname record check A Cname, (or Canonical Name) record is a type of resource record in the Domain Name System (DNS) that specifies that the domain name is an alias of another, canonical domain name. This helps when running multiple services (like an FTP server and a webserver; each running on different ports) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com. and www.example.com). To check the Cname records on the network, you can use a Microsoft utility called DNSLint. This utility helps diagnose general DNS name resolution issues. DNSLint is a command-line utility that you can run on your network. You can download DNSLint directly from Microsoft:

http://download.microsoft.com/download/2/7/2/27252452-e530-4455-846a-dd68fc020e16/dnslint.v204.exe

There are many different uses for DNSLint however you will be using this to check that there are Cname records for all the domain controllers that are part of the network. You could do this manually using DNS Manager on the Forest Root Domain Controller, and expanding the server, Forward Lookup Zones, _msdcs and ensuring there is an alias (Cname) record for every domain controller. This is likely to take some while because the servers are identified by their GUIDs so you would need to compare the entries in DNS Manager with the GUID of each of the domain controller. Using DNSLint is much simpler, (and quicker), because, at a command prompt you simply type:

dnslint.exe /ad/s



Once DNSLint has run, it will generate a .htm log file in the same file that DNSLint was installed in. You should check this log file for any A record errors as this suggests there are missing Cname records for the domain controllers that are part of the network.

Note: The DNSLint installer will not run on a Windows Server 2008R2 server

however the utility can still be used on them. If you intend to run this utility on the server operating system, extract it on a computer and then copy the utility to the Windows Server 2008R2 server.

DHCP Configuration The next set of checks makes sure that DHCP is configured correctly on the network so that a Community Connect 4 management server can be added. As well as issuing IP addresses to clients on the network it is also used by services on the network to locate information for the network itself to function, including the CC4 management server once it is added. DHCP Scope option check Local DNS entries are held in a Local node in DNS Manager. In order for resources on the network to be able to find these resources, there should be an entry in DHCP Manager pointing to this local category that is in DNS.



Also, all of the servers on the network, which serve as a DNS server for computers to query, should also be listed in DHCP Manager. This information is provided to computers when they are issued with an IP address from DHCP Manager. We should check that all of this information is available in DHCP Manager and if not add or update it to match the requirements of Community Connect 4. To check this exists:

1. On the server which is running DHCP Manager, (this is typically the Forest Root Domain Controller), open DHCP Manager.

2. In the left-hand pane, expand the name of the server, expand the DHCP scope configured for the network and expand ‘015 Scope Options’.

3. In the right-hand pane, ensure there is an option for: 015 DNS Domain Name and the option name is set to ‘Local’.

4. Also check there is the following entry: 006 DNS Servers and this option contains all of the IP addresses of the servers that act as DNS servers for the network.



Should there not be an option for DNS Domain Name then you can add it as follows:

1. In DHCP Manager, in the left-hand pane, expand the name of the server, expand the DHCP scope that has been configured and right-click on ‘Scope options’.

2. From the sub-menu, choose ‘Configure options…’ and from the list presented, click on ‘006 DNS Servers’.

3. In the IP address pane, add in the IP address of the DNS Servers on the network, remembering to click the Add button after entering the IP address. Once you have entered the IP addresses, click OK.

DHCP Lease Time check When DHCP Manager issues an IP address, it is provided to the device for a set length of time. This could range from a few hours or indefinitely. We recommend DHCP lease times for wired clients, (such as desktop computers), should be leased for eight days. When a computer is issued with an IP address, the clock starts ticking. After eight days, the computer will contact DHCP Manager again to see if it can carry on using the IP address it was originally issued with. If it can, the clock is reset and it carries on using the IP address it already has. If that IP address has been claimed by another device then it will request a new IP address from the range and use that going forward. Eight days is a useful time because it allows devices to be switched off for a week and one day, and still be able to use it’s original IP address, meaning that lots of IP addresses will need to be updated following on from a half-term. To check the DHCP Lease Time in DHCP Manager:

1. In DHCP Manager, right-click on the DHCP IP address scope under the server listed in the left-hand pane and choose Properties.

2. On the General tab, check the ‘Least duration for DHCP clients’ is set to 8 days. If it isn’t we recommend you change this time period to 8 days and click OK to save the changes.



3. Close DHCP Manager. As you can see, there are only two checks that need to be carried out by DHCP Manager, and these are to make sure the options are configured following Microsoft and our best practice advice.

Act ive Directory Checks Active Directory is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Active Directory provides a central location for network administration and security. Essentially, it is a database of objects that exist on the network. Windows Server computers that run Active Directory are called domain controllers. An AD domain controller authenticates and authorises all users and computers in a Windows domain type network - assigning and enforcing security policies for all computers and in a stand-alone Windows Server environment, may be used for installing or updating software. For example, when a user logs into a computer that is part of a Windows domain, Active Directory checks the submitted password and determines whether the user is a system administrator or normal user. In both Community Connect 3 and a stand-alone Windows Server environment, the Active Directory is a mission-critical component of the network – it is often where all the information for the network is held. In Community Connect 4 it is still mission-critical but as you may know, we also have the Community Connect 4 management database as well which holds lots of information about the resources on the network. Before the Community Connect 4 management server is added, we need to make sure Active Directory is functioning correctly and all the domain



controllers that exist on the network have the ability to access, change, update and replicate Active Directory changes to the other domain controllers on the network. Active Directory replication check As we have already seen, all domain controllers on the network hold a copy of Active Directory. This also means any domain controller can update the data that is held in the Active Directory database. Once a change has been made in the copy of the Active Directory on a domain controller, that change must be replicated to the other copies of Active Directory, (on the other domain controllers), on the network. This is known as Multimaster replication. Multimaster replication is a method of database replication that allows data to be stored by a group of computers, and updated by any member of the group. All members are responsive can provide data from the database when requested, (for example, validating user logons). The multimaster replication system is responsible for propagating the data modifications made by each member to the rest of the group, and resolving any conflicts that might arise between concurrent changes made by different members. Multimaster replication can be contrasted with master-slave replication, in which a single member of the group is designated as the "master" for a given piece of data and is the only node allowed to modify that data item. Other members wishing to modify the data item must first contact the master node. Allowing only a single master makes it easier to achieve consistency among the members of the group, but is less flexible than multimaster replication. The main reason for using multimaster replication is to increase the availability of data, and faster server response times when data is read or written.

Windows Server 2003 replication If you have Windows Server 2003 domain controllers on your network then you can check that Active Directory replication changes are being carried out using the utility called replmon. In fact, replmon is one of a number of utilities that you can use to check Active Directory replication but this is the simplest because it uses a graphical interface to show you the results of replication tests. To use replmon to check the replication of Active Directory between Windows Server 2003 domain controllers:



1. From the Start menu on the Forest Root Domain Controller, choose Run and type in replmon, and press Enter.

2. In the left-hand pane, right-click on Monitored Servers and choose ‘Add modified Server…’ from the sub-menu.

3. The ‘Add Server to Monitor’ wizard will start. Choose ‘Search the directory for the server to add’ and in the field type in your network’s domain name, (for example schoolname.internal). Press ‘Next >>’.

4. From the ‘Add Server to Monitor’ screen, ensure ‘Below is a list of Sites that are available from Active Directory. Expand the site and select a server to monitor’ is selected. Expand the site in the top pane and choose the Forest Root Domain Controller from the list of domain controllers, and click Finish. Active Directory Replication Monitor will now open.

5. In the left-hand pane, expand the server and you will see each of the Active Directory partitions, (these are what are replicated to the other domain controllers on the network).

6. When you expand each of the directory partitions you will see the server you are connected to, and it’s replication partners – these are the servers that the server you are monitoring replicates it Active Directory to. If there is a replication problem then you will see a red cross against the server icon. Clicking on this will display information in the right-hand pane why replication has failed.



Note: In the previous screen, replication hasn’t been able to take place for all of the Active Directory partitions, as indicated by the red crosses against the icons. This is intentional to demonstrate what you would see if there was replication issues on a domain controller.

7. Repeat steps 1-5 on all your domain controllers

Windows Server 2008 replication checks Windows Server 2008 doesn’t ship with replmon however we can check any replication problems using the command line. On a Windows Server 2008 domain controller we use the repadmin utility to check for any replication problems on these domain controllers. Note: You should use repadmin if your domain controllers are using Windows

Server 2003 and Windows Server 2008. To check replication on a network running just Windows Server 2008, or a mixture of domain controllers with the two supported operating systems on:

1. On the Forest Root Domain Controller open a command prompt from the Start menu and type in: repadmin.exe /replsummary repadmin will carry out replication checks against the Forest Root Domain Controller’s replication partner(s) and return the results.

2. Check the results for any numbers in the Fail column from the results returned.

3. Repeat steps 1 and 2 above on the replica domain controllers on your network.

Replication USN rollback check A domain controller tracks objects in Active Directory based on their Update Sequence Numbers (USN). Every object in Active Directory has a USN. As objects are modified, the USN increases, in a similar way to the odometer on a car. The latest USN on each domain controller is called the “high water mark”. During replication each domain controller compares its USN high water mark with the USN high water mark of its replication domain controller.



USN rollback happens when an older copy of Active Directory is restored but the computer fails to notify the other domain controllers that it was rolled back to an out-of-date copy of AD (and therefore that its high water mark has also rolled back). The result of this is out-of-date or lingering object will remain in the copy of Active Directory that has been restored. This could potentially result in inconsistent Active Directory data across the domain. For example, a user’s password could be different in the copy of Active Directory that has been restored when compared with its replication partners but the data it has for the object has a lower watermark. To help prevent inconsistent data, Active Directory will attempt to protect the data and if it detects a USN rollback it will log an error in Event Viewer. To check for USN rollback errors:

1. On the Forest Root Domain Controller, open Event Viewer.

2. Open the Directory Services log and look for any errors with the following event ID 2095. If there are these errors then a USN rollback has been detected.

3. Repeat steps 1 and 2 on each of your replica domain controllers. If USN rollbacks are detected then this is potentially a serious error and is normally repaired by removing the domain controller from the domain and then adding it back again using the dcpromo utility. Before attempting this you should speak to your support provider before proceeding.

Replication journal wrap check If you’ve attended RM Training’s Masterclass Essentials course you will have learnt that on a Community Connect 3 and Community Connect 4 network, Group Policy Object Templates are replicated to all domain controllers from the SYSVOL folder. This replication is carried out by the File Replication Service and as well as being used to replicate Group Policy Object Templates, it can also be used to other files required on each domain controller, such as logon scripts. It is important that the File Replication Service is working correctly and able to replicate files in the SYSVOL share to all domain controllers before a Community Connect 4 management server is added and we do this by looking in Event Viewer for Journal Wrap errors. The USN journal is a log of fixed size that records all changes that occur on NTFS formatted partitions. The File Replication Service monitors the NTFS USN journal file for files in FRS replicated directories, typically SYSVOL, as long as the File Replication Service is running.



Journal wrap errors occur if a sufficient number of changes occur while the File Replication Service is turned off in such a way that the last USN change that the File Replication Service recorded during shutdown no longer exists in the USN journal during start-up. The risk is that changes to files and folders for the File Replication Service replicated directories may have occurred while the service was turned off, and no record of the change exists in the USN journal. To guard against data inconsistency, the File Replication Service asserts into a journal wrap state, effectively protecting SYSVOL. If the above happens, a warning will be logged in the File Replication Service event log. To check for Journal Wrap warnings:

1. On the Forest Root Domain Controller open Event Viewer and select the File Replication Service log.

2. In the event log, check for any warning log entries from ‘NtFrs’ with event ID 13568.

3. Repeat steps 1 and 2 on the replica domain controllers.

If you see any of the above warnings then the domain controller has entered a journal wrap state and this may require the SYSVOL folder being rebuilt. This could have serious implications to the state of the network so I would recommend you contact your support provider before making any changes.

Replication Event Viewer Diagnostics Another check related to the File Replication Service is to make sure that it is actually replicating correctly to its replication partners that are part of the domain. We do this by using the File Replication Service event viewer again, looking for an event with the ID 13516. This tells us that the File Replication Service can successfully replicate the files in SYSVOL. The individual steps to carry out this check are:

1. On the Forest Root Domain Controller, if you Event Viewer isn’t open from the previous check, open it from Administrative Tools on the Start menu.

2. Select the File Replication Service in Event Viewer and check that the most recent log entry has the event ID 13516 with the following description: The File Replication Service is no longer preventing the computer from becoming a domain controller. The system volume has been successfully initialised and the Netlogon service has been notified



that the system volume is now ready to be shared as SYSVOL.

3. Repeat the above steps on the replica domain controllers. If the last logged event in the File Replication Service event log isn’t the one in step 2, above, then this suggests that the File Replication Service is unable to replicate the files in SYSVOL to its replication partners. Other events logged should suggest why it isn’t able to replicate and you should solve these issues with the help of your support provider. Active Directory configuration As part of the pre-installation checks before adding a Community Connect 4 management server, we will check that Active Directory in your domain is configured correctly. This will ensure that once the management server has been added data can be read from and written to Active Directory in your existing stand-alone Windows or Community Connect 3 domain.

Active Directory FSMO check Earlier in this paper I described Active Directory as multi-master: all domain controllers hold a copy of the Active Directory and all domain controllers can make changes to it which are then replicated to the other domain controllers on the network. Generally, that statement is correct but there is certain data that can only be written to Active Directory from a single domain controller. these are known as the Flexible Single Master Operator roles, or FSMO roles. There are five FSMO roles in Active Directory:

• Schema master.

• Domain naming master.

• Infrastructure master.

• Relative ID (RID) master.

• PDC emulator. Typically these FSMO roles are held on the Forest Root Domain Controller and both Microsoft and RM recommend these are never moved, even though it is possible. You can check which domain controller holds the FSMO roles before checking the domain controllers know this by following the article below: http://www.petri.co.il/determining_fsmo_role_holders.htm



It is important that all the domain controllers on the network know which of them holds the FSMO roles and you should check this is the case. To check that the FSMO role holder is known:

1. On a replica server open a command prompt.

2. In the command prompt, type in the following: netdom query fsmo

dcdiag /e /test:KnowsOfRoleHolders

3. Check the results that the server that holds these roles is the one that is returned from the above tests.

Active Directory Dcdiag diagnostics Dcdiag is a command-line tool that analyses the state of domain controllers in a domain and reports any problems to assist in troubleshooting. As an end-user reporting program, Dcdiag encapsulates detailed knowledge of how to identify abnormal behaviour in the domain, forest or enterprise. Dcdiag displays its results in the command prompt or in a text file, which can be checked at a later time. Dcdiag consists of a framework for executing tests and a series of tests to verify different functional areas of the network. This framework selects which domain controllers are tested according to what you ask it to test. For example,



if you suspect there are Active Directory replication issues, dcdiag can confirm this by running the tests. To run, and check, the Dcdiag tests:

1. On a domain controller, open a command prompt and enter: dcdiag /e /v /c /skip:dns > c:\dcdiag.txt Note: For a detailed description of the switches used above,

and the others available when using dcdiag, please see the following Microsoft Knowledge Base article:

http://technet.microsoft.com/en-us/library/cc757689(v=ws.10).aspx

2. On the root of the C:\ drive, locate the file dcdiag.txt created by the utility and double-click on it so it opens in Notepad.

3. Examine the results from dcdiag for any errors. It may prove quicker to search for the word FAIL. You can ignore any errors for the following: - MachineAcccount test: You may see this test fail on a

Community Connect 3 network.

- Event Log errors: These are captured separately although dcdiag may log this a failed test.



If any tests have failed from dcdiag then you should rectify the failed tests before we carry out the pre-installation checks. If necessary, contact your support provider for assistance.

Active Directory NetDiag Diagnostics NetDiag is a utility for Windows Server 2003 domain controllers that checks the network availability. NetDiag will test for, amongst other things:

- DNS problems. - Microsoft Software Update installations. - Network card bindings. - Domain Controller LDAP communication.

Note: NetDiag cannot be used on a Windows Server 2008 domain controller. NetDiag is run from the command prompt, and as with Dcdiag you can pipe the results in to a text file. To use NetDiag to test the network communication of your domain controllers:

1. On the Forest Root Domain Controller, open a command prompt.

2. In the command prompt window, type: netdiag /v > c:\netdiag.txt

3. From the root of the C:\ drive, locate the file netdiag.txt and double-click on it so it opens in Notepad.

4. Check for any errors by searching the text file for the word ‘fail’. You can safely ignore any failed tests for: - Device\Nwinklpx features.



- TCP, UDP and IP statistic failures.

5. Repeat steps 1-4 on your replica domain controllers. Any other tests that have been failed by Netdiag should be resolved before we carry out the pre-installation checks for the Community Connect 4 management server installation.

Global Catalog check Global catalog servers are used in Windows Server operating systems to reduce the amount of network traffic when searching for information about objects, (for example user names). This is particularly useful in a multi-domain Windows Server network that is part of an Active Directory forest. So, for example, a user can log on to a computer that is part of a domain that isn’t the one where the user object exists in Active Directory. Rather than the domain controller that is attempting to validate the user’s credentials having to contact the domain where the user object exists, it can contact a local global catalog server that will hold this information, thus reducing the amount of network traffic. We recommend all domain controllers are configured as global catalog servers. If you currently have a Community Connect 3 network then all your domain controllers will be configured as global catalog servers however it is still worthwhile running this test whether you currently have Community Connect 3 or a stand-alone Windows Server network. To check if all the domain controllers, which are part of your domain, are global catalog servers:

1. Open a command prompt and type in the following two commands: dsquery server –forest –isgc and press enter. dsquery server and press enter. The list of domain controllers from the first command should match the list of domain controllers from the second list. If they don’t then the additional domain controllers on the second list are not configured as global catalog servers.



To configure a domain controller as a global catalog server please see the following web page:

http://www.petri.co.il/configure_a_new_global_catalog.htm (Windows 2003 Server) or: http://technet.microsoft.com/en-us/library/cc794934(v=ws.10).aspx for Windows Server 2008.

Windows security group check When the Community Connect 4 management server is added to your network there are some standard Windows security groups that are added. If you have a Community Connect 3 network currently, then these security groups will already exist and it is likely they are being used to set permissions as they will be on Community Connect 4. If you have a stand-alone Windows network however, you may be using security groups with the same names as we will add when commissioning the Community Connect 4 management server. It is worthwhile, on a stand-alone Windows server network performing a manual check of the security groups and, if possible, renaming them so they are unique from the security groups that will be added when we add the Community Connect 4 management server. The list of security groups required for the Community Connect 4 management server to perform correctly are:



Accessibility Library System

Advanced Station Security Managed Stations

Associates Management Information System

Authorised ManagerType Member Servers

Build in Progress Station Security MIS Manager

Build Warnings Network ManagerType

Centralised User Management ManagerType

No GPO Security

CyberCafe StationType No Station Security

Delegate ManagerType Non-Teaching Staff

EasyLink Password Management ManagerType

EDI System Personal StationType

Education Management System Password Management ManagerType

Finance System Personal StationType

Guest UserType Printer Credits Management ManagerType

Internet Disabled Shared Desktop StationType

Legacy Application Users Shared Laptop StationType

Staff Print Operators Staff UserType

Standard Station Security Station Setup

Students Teaching Staff

Terminal Server StationType User Controller ManagerType

Policy Managers



Third party applications

When the Community Connect 4 Management Server is added to your network, we will install two applications on your domain controllers. These are:

- Microsoft .net 2.0 SP2 - PowerShell 2

When installing Microsoft .net 2.0 SP2 you may be prompted to restart the domain controller following its installation. You may want to consider delaying this installation until a time when it is appropriate. You can download and install Microsoft .net 2.0 SP2 from the following webpage: http://www.microsoft.com/en-gb/download/details.aspx?id=1639 You can download and install PowerShell 2 from here: http://www.microsoft.com/en-us/download/details.aspx?id=4045 Note: This update is called the ‘The Windows Management Core package’. Once you have downloaded these applications, install them on your domain controllers following the standard setup options. The RM pre-investigation check and management server commissioning At a time convenient to you we will remotely connect to your network and carry out the pre-investigation check. If you have followed this paper then this should be a quick and simple process because we will check the settings that we have examined previously. There will also be some additional checks using special utilities we have created to make sure the network is prepared for adding a Community Connect 4 management server. Once the pre-investigation check has been carried out, and any issues rectified, an RM authorised commissioning engineer will add the Community Connect 4 management server and any User Storage Servers to your existing network. Once this is commissioned you will have what is known as a hybrid network – one of the two types of network:

- A stand-alone Windows Server based network with at least a Forest Root domain controller and, optionally, replica domain controllers, and member servers such as Terminal or Exchange



servers, and, following the commissioning process, a Community Connect 4 management server.

- A Community Connect 3 managed network with a Community Connect 4 management server.

Forest Root

Replica Domain Controllers

Member Server

CC4 First

Server

What is the Community Connect 4 Management Server? A Community Connect 4 Management Server is a Windows Server 2008R2 member server that is part of your domain. This member server has all the Community Connect 4 management tools and the components required for the network to be managed installed on it. These include:

- A Community Connect 4 management database built using PostGreSQL.

- A package repository for deploying applications to Community Connect 4 Managed computers.



- Operating system build images for installing Windows XP or Windows 7 on clients.

You may also have Community Connect 4 User Storage Servers added to the network at the same time. These servers are designed to hold user data including their profiles and home folders. As you migrate over to using the Community Connect 4 management tools all the time, it is likely you will have additional User Storage Servers added to your network.

The hybrid network During the phase where you have your existing management tools and the Community Connect 4 management tools. Ultimately you want to be using only the Community Connect 4 management tools to manage the computers, users, packages and other features of the Community Connect 4 management toolset. In the next part of this paper, we will look at how you manage the network while it is in this hybrid state. Note: We recommend you only manage a hybrid network for a maximum of

six months.

Managing your hybrid network In this section of the paper we will look at how you manage your network during the hybrid phase – when you have stand-alone users and computers, and when you still have the Community Connect 3 management tools available. The first section is for stand-alone networks. The second part is if you have a Community Connect 3 network today.

Planning the transition to Community Connect 4 from a stand-alone Windows network If you had a stand-alone Windows Server network before the addition of the Community Connect 4 management server you have the flexibility of still being able to use the built-in Windows Server management tools. This means that during the transition time you can gradually move your users, computers, and member servers over to the Community Connect 4 management tools.

User accounts



When planning how you will manage user accounts going forward you need to consider how you are going to configure the computers that are part of the domain. The main considerations are:

- Are you going to manage all your computers through the Community Connect 4 management tools?

- Are you going to have a mixture of Community Connect 4 managed computers and stand-alone Windows clients, (i.e. computers that don’t have the Community Connect 4 management tools for clients installed)?

It makes sense that if users will be using Community Connect 4 and stand-alone clients that users don’t have two user accounts – one for the stand-alone clients and one for the Community Connect 4 managed clients. This is bound to cause confusion and generate lots of calls to the network support team. The table below shows the features that are made available to user accounts that are managed by Community Connect 4 and those managed by stand-alone tools:



Community Connect 4

managed user account Stand-alone managed

user account Feature Vanilla

computer CC4

computer Vanilla

computer CC4

computer CC4 Start menu û ü ü ü Error-free start-up û ü ü ü CC4 Computer registry policies û ü ü ü My Connect (limited) û ü û ü LST Tasks û ü û ü CC4 Package deployment û ü û ü Software restrictions û ü û ü CC4 Computer build û ü û ü CC4 User registry policies ü ü û ü CC4 Acceptable Use Policies û ü û ü CC4 Printer mappings û ü û ü CC4 Drive mappings û ü û ü My Connect (fully working) û ü û û CC4 Program Sets û ü û û As you can see from the table above, a user account that is managed by the Community Connect 4 management tools will have a poor experience when logging on to a stand-alone computer whereas users who are managed by the Windows stand-alone tools can enjoy most of the features of Community Connect 4. As a result of what a user ‘sees’ when they log on to a stand-alone computer, we recommend that during the hybrid network phase, (and going forward if you intend to keep stand-alone Windows clients), we recommend the following:



- When adding new user accounts, if the user account is going to

be used on stand-alone Windows clients, create them using the management tools you used before the Community Connect 4 management server was added.

- If your intention is to manage all computers on the network using the Community Connect 4 management toolset, once all the computers have been added to Community Connect 4, migrate your user accounts previously managed by your stand-alone management tools to the Community Connect 4 management toolset.

- During the transition period, manage your stand-alone user accounts using the stand-alone tools you have used before the Community Connect 4 management toolset was added.

Configuring user management on your hybrid network During the hybrid period of your network, it is likely users will be logging on to stand-alone and Community Connect 4 managed computers. As we have seen from the table above it is possible for users managed by the stand-alone tools to have a Community Connect 4 experience when they log on to a Community Connect 4 managed computer whereas when they log on to a stand-alone computer, the environment is configured for those computers. This is achieved by modifying the behaviour of how computer policies, (which are Group Policy Objects), and when they are applied. You also have the option of configuring these so that they are applied to all Community Connect 4 computers or a subset of them.

Preparing existing user policies for coexistence with Community Connect 4 The user’s home folder on Community Connect 4 uses the N: drive as their home folder. We recommend that you modify your existing users so that their home folder is also the N: drive. Because this setting is applied through the user object in Active Directory, the settings needs to be consistent across stand-alone and Community Connect 4 managed computers. It is worth noting that Community Connect 4 uses several drive mappings and we recommend that you don’t use these drives for home folders if you are not going to follow our best practice advice. The drive letters used by Community Connect 4 are:

L: Mapped to the share RMManage on the Community Connect 4 management server.



N: Mapped to the user’s home folder on the Community Connect 4 management server or a user storage server.

P: Mapped to the RMPublic share on the Community Connect 4

management server. T: Mapped to the RMStaff share on the Community Connect 4

management server. V: Mapped to the RMMultimedia share on the Community Connect

4 management server.

W: Mapped to the RMShared Documents share on the Community Connect 4 management server.

Drives U:, Y:, and Z: are also used on Community Connect 4 managed clients as the virtual CD/DVD/Blu-ray drives for the use of virtual disc images. You can change which drive is used to access the user’s home folder by modifying the properties in Active Directory Users and Computers. The following Microsoft Knowledge Base article details how you can make this change for your existing user accounts: http://support.microsoft.com/kb/816313

User profile redirection CC4 uses roaming profiles to ensure that users get a consistent experience when they move between different computers on the network. If your existing users have roaming profiles, it is important to ensure that CC4 is configured correctly to match. CC4 handles data in certain folders by redirecting it to a location on the network for each user, as shown in the table below: Folder Redirects to Application data \My Settings\Application Data Downloads Favourites \Favourites Links \Links Searches \Searches My Documents My Pictures \My Pictures My Music \My Music My Pictures \My Pictures Desktop (for staff only) \My Settings\Desktop



It is common practice to redirect such user profile data to network locations, and this may already be configured on your network. If not, we strongly recommend that you do so, for the following reasons:

• It will speed up the processing of logging on and off: each computer will no longer need to copy data from the server during logon, and back again during logoff.

• It will keep down the size of roaming profiles stored on computers, making them less likely to use lots of disk space.

• It will ensure a more consistent experience when users transfer between CC4 and vanilla computers.

These settings are held in a Group Policy Object and make changes to the registry when the user logs on. For more information on how to configure user profile redirection, then please see the transition guide for stand-alone Windows networks that will be available in the RM Knowledge Library.

Set CC4 computer policies to enforce CC4 settings for all users Group Policy Objects are configured in the Active Directory at the Organisational Unit level. On a standard Community Connect 4 network, all Group Policy Objects are applied at the highest ‘Community Connect 4 Organisational Unit’. In a hybrid state, stand-alone user accounts will exist outside of the Community Connect 4 Active Directory structure so, by default, they won’t be applied when a user logs on to a Community Connect 4 managed computer. In order for Community Connect 4 User Policies to be applied when a stand-alone managed user logs on, you need to make a change to the Computer policies that are applied to Community Connect 4 managed computers. We make these changes using the RM Management Console that allows us to edit Registry Policies. To enforce User Policies to stand alone users when they log on to a Community Connect 4 managed computer:

1. Login to the RM Management Console as a Community Connect 4 system administrator level user

2. In the left-hand pane, expand Registry Policies, then Computer Policies.

3. You now have two choices:



If you want Community Connect 4 User Policies to be applied to all users regardless of the type of Community Connect 4 managed computer they log on to, then expand Global Settings and choose ‘All computers’. If you only want Community Connect 4 User Policies to be applied to a particular type of Community Connect 4 managed computer, for example desktop computers, then select the ‘Shared desktop’ computer policy.

4. In the middle, (Categories), column, select Logon.

5. Place a tick in the setting ‘Apply CC4 user policies to all users’ and click the Save button.

6. Repeat steps 3-5 if you have NOT set this settings in the All Computers computer policy, and you want this setting to be applied to other computer types, for example shared laptops

This new setting will be applied to any Community Connect 4 managed computers the next time they are restarted.

Creating Community Connect 4 User Policies for hybrid users For the users who are managed by the stand-alone user management tools you may want to create custom user policies for when users are logging on to Community Connect 4 managed computers. This might be useful if you want to remove some of the Community Connect 4 functionality that isn’t available to stand-alone managed user accounts. Another example where this might be useful is if you don’t use drive N: for these users’ home directories. These custom user policies can be created using the RM Management Console, in the Registry Policies node. To make this easier, you can clone an existing Community Connect 4 policy and then use that as the base to create your customised settings. To create a custom policy for your stand alone users:

1. In the left-hand pane of the RM Management Console, expand Registry Policies, and expand User Policies.

2. Right-click on the User Policy you want to base your customised policy on and choose Clone.

3. Provide your new policy with a name, (for example ‘Hybrid Standard Users’ and click OK.



Your new policy will now appear in the RM Management Console with the other User Policies.

4. There are some changes we recommend you make, including:

- Removing the Change Password option from My Connect as this doesn’t work for stand-alone managed users.

- In the General category, make changes to the Desktop, My Documents, My Pictures, My Music, My Videos and My Network Places if you aren’t using the N: drive for these user’s home folder drive.

- Configure the location of the Application Data folder for user’s home folders.

- Any Start menu changes you want for stand-alone managed users. For example, consider the ‘Cascade sub-folders’ and ‘Prevent changes to the Taskbar and Start Menu’ settings.

5. Create additional hybrid user policies for every type of stand-alone

managed users you want to configure. More detailed information on the rational behind these changes will be included in the transition guide, which is designed to help you manage both sides of your network during the transition period. When you create a User Policy in the RM Management Console it creates a security group that gives users access to that policy. If you created a custom user policy called Hybrid Standard, a security group would be created called ‘xxx Hybrid Standard’, where ‘xxx’ represents the three-letter site code for your school. After you have created the policy the final stage is to add the users, through Active Directory Users and Computers’ to the security group that the Community Connect 4 management tools has created for you. Once the users have been added to this group, the next time the user logs on to a Community Connect 4 managed computer, (and the enforce CC4 user policies setting we looked at earlier has been applied to the computer policy has been set), the user policy will be applied.

Providing access to Community Connect 4 Program Sets Program Sets control what applications a user has access to on a Community Connect 4 managed computer. Be default, these will only be applied to user accounts that are managed by the Community Connect 4 management tools



that, until you migrate the user accounts over from your stand-alone management tools, won’t be. Providing access to Program Sets for this group of users though is very easy and requires changing the security groups that have access to the Community Connect 4 Program Sets:

1. In the RM Management Console, in the left-hand pane, expand Software and expand Program Sets. In the right-hand pane, the Program Sets will be displayed.

2. For each Program Set you want stand-alone managed users to have access to, double-click on each one and, on the Groups tab, click the Add button.

3. In the Select Groups window, select a security group that the stand-alone users are a member of. For example, if you have created custom hybrid user policies you could use those groups, (e.g. the ‘xxx Standard Hybrid’ security group we looked at earlier in this paper). If you want all users to have access to this Program Set, (The Core Programs Program Set is a good example of one everybody is likely to want access to), simply give the Domain Users security group access to it.

4. Once you have selected the groups, click OK and then OK again in the Program Sets window to apply the changes.

The next time the users who are a member of the security group you added to the Program Set log on to a Community Connect 4 managed computer, they will receive the Program Set in their Start menu.

Migrating stand-alone user accounts to the Community Connect 4 management tools There will come a point during the migration process where you will want to migrate your users from the stand-alone management tools over to the Community Connect 4 management toolset. We have provided a user migration management tool, which makes moving the user’s over so they can be managed in the RM Management Console. Before you run the user migration tool, there are some requirements that must be met before it will successfully migrate the user accounts:



- The user account’s profile must be stored on a network share.

- The user account’s home directory must be stored on a network share and not locally on a computer.

- Although not a strict requirement, the user’s home folder should be mapped to drive N:. If it isn’t then the migration will still take place however there is a risk of a network drive clash with one of the network drive letters used by Community Connect 4.

When the user migration tool is run, if any of the above requirements aren’t met then a warning will be displayed before the migration takes place. You can download the User Migration tool from the RM Knowledge Library, searching for the download article DWN2720357. Once you have downloaded the .zip file from the RM Knowledge Library, extract it to a location on the CC4 management server. There are two stages to migrating users from the stand-alone Windows management tools to the Community Connect 4 one:

1. Migrate the users in to the Community Connect 4 Active Directory structure.

2. Migrate the user data to a Community Connect 4 management server or User Storage Server.

Migrate the users in to the Community Connect 4 Active Directory Structure There are five types of users on a Community Connect 4 managed network:

- Students.

- Teaching Staff.

- Non-teaching Staff.

- System Administrators.

- Associates. To allow the user migration tool to import users, the accounts must be arranged by type in their own Organisational Units.



Users inside your source Organisational Unit can be arranged in a hierarchy of sub-Organisational Units, (for instance, by year of entry), or simply grouped together immediately inside the Organisational Unit. Each time the user migration tool is run, it will prompt for the source Organisational Unit to use, and the type of user the Organisational Unit contains. Therefore, to import all five types of user listed above, you would run the tool five times – once for each type, and with a different source Organisational Unit each time. The root of each source Organisational Unit will be the root of the resulting CC4 user hierarchy. To migrate the users in to the Community Connect 4 Active Directory structure:

1. Log on to the Community Connect 4 management server as a System Administrator level user.

2. Browse to the location where you extracted the User Migration tool after you downloaded it from the RM Knowledge Library.

3. Double-click the file: 1-UserMigrate.cmd to run the tool.

4. In the window, type in a letter to represent the type of user you want to migrate:

S = Student T = Teaching Staff N = Non-Teaching Staff * = System Administrator A = Associate

And press Enter.

5. Enter the path to the source Organisational Unit where the migration tool will move the user accounts. Press Enter

The user migration tool now validates each user found within the chosen source Organisational Unit. It checks that the conditions listed above are met. If not, warnings are displayed and you are given the opportunity to stop the migration so you can modify the user account details as required. If all the requirements are met, the user migration tool processes each user and sub-Organisational Unit stored within the chosen source Organisational Unit. Progress is displayed on the screen.



When all the users are validated, Community Connect 4’s User Manager User Upgrader runs and imports the users into the Community Connect 4 database. This process may take up to thirty minutes, and does not give progress feedback. The command window closes when the import is finished. You can confirm the users have been successfully migrated by:

1. Logging on to the RM Management Console.

2. In the left-hand pane, expand Users and select the type of user you have just migrated.

3. In the right-hand pane, you should see the user accounts you have just migrated.

4. Double-click on one of the imported users and the Properties window will open.

As well as being able to see, and view the properties of, the user accounts in the RM Management Console, the User Migration tool also creates a log file in the a folder called ‘Logs’ which can be found in the folder where the User Migration tool was launched from. There is only ever one log file and every time you run the tool it appends the migration log file data to the end of this single file. Now the user accounts exist in the RM Management Console, (and the Community Connect 4 Active Directory structure), the second part of the migration is to move the user data from the stand-alone server to the Community Connect 4 management server or a User Storage Server.

Migrate the user data to a Community Connect 4 management server or User Storage Server. After their user accounts have been migrated, users will be able to log on to and use Community Connect 4 computers, so you may choose to delay the migration of user home folders to the Community Connect 4 server until a more convenient time. If you do delay the migration of the user data then you won’t have full management functionality in the RM Management Console. Until the data has been migrated you won’t be able to:

- Move the user account.

- Clone the user account.



- View or edit the user disk quota.

- Rename the user.

- Carry out a health check of a user account(s).

- View the user hierarchy via. the RM Management Console. User data is moved on a folder-by-folder and server-by-server basis. For example, you can choose to move all user data from the ‘Year 9’ folder on ‘Server002’ of your stand-alone network to the Community Connect 4 management or User Storage server. Users in Community Connect 4 are usually stored in folders, although it is possible for them to exist directly under the type of user’s root folder, for example, Students. When your existing Active Directory users data was migrated to Community Connect 4, the existing folder structure (the Organisational Unit structure in Active Directory) was maintained. Although this folder hierarchy is not visible through the RM Management Console, you can see the folder to which each user belongs by adding a new column to the Users list, as follows:

1. In the left-hand pane of the RM Management Console, expand Users and click on one of the lists that represent the types of users in Community Connect 4.

2. In the right-hand pane, right-click on the column headers and from the sub-menu choose Folder Path. This will display the folder path in the list of users in the RM Management Console that was created when the user data was migrated in to the Community Connect 4 management tools.

This information is useful because you can use it when you run the second migration tool as the location the user data is to be moved to.



To migrate the user data to the Community Connect 4 management or User Storage Server:

1. On the Community Connect 4 management server, browse to the location you extracted the User Migration Tool earlier.

2. Double-click the file: 2-MoveUserData.cmd and press Enter.

3. In the command prompt window that opens, type in the appropriate letter for the type of user data you want to migrate, (for example, S for student data).

4. A list of source folders is then displayed. This is the list of folders that contain the user home folder data, with a number preceding each folder. Enter the number of the folder that you want to migrate the data to and press Enter.

5. If there is more than one source server containing user data then you will also be prompted to select the source server for the data you want to migrate. Some of the users that will have their data migrated will be displayed. This is an opportunity for you to check that you are migrating the correct user data. If you have the correct users then press Enter. The data migration tool will then run a check to ensure the data is accessible. If it isn’t then a warning will be displayed and at this point, you can cancel the migration if you wish. If there aren’t any problems, or you don’t cancel the move, then the data will be migrated on to the Community Connect 4 managed servers.

Note: Depending on the amount of data this may take some

time.

6. Once the data has been migrated, the tool displays a message stating that it will now update the user’s properties in Active Directory so the user objects will point to the new location of the user’s home folder, which now exists in the Community Connect 4 data structure. Press Enter to update the user objects in Active Directory.



7. Once the migration has taken place and Active Directory has been updated, a summary screen is displayed.

Although the data has now been migrated and the user object properties in Active Directory now points to the new location, the security permissions on the user’s home folders on the Community Connect 4 managed servers will not be correct. To set the correct permissions, a Health Check needs to be run in the RM Management Console. A Health Check is a tool that corrects security permissions on Community Connect 4 created files and folders and can be used as a troubleshooting tool when you are carrying out day-to-day management of Community Connect 4. To carry out a health check on the user data you have just migrated:

1. In the RM Management Console, expand Users and expand User Servers, then click on the server which you have just migrated the user data to, (This could be the Community Connect 4 management server or a User Storage Server).

2. Right-click on the type of user you have just migrated, (for example, Students), and choose Health Check.

3. Tick the ‘Health check recursively’ box and click the Yes button. The health check will now take place and set the permissions on the user’s home folders stored on the server.

4. In the left-hand pane of the RM Management Console, you can select Health Check to view its progress.

You can review the user data migration by checking the log files that are created by the data migration tool. These logs are stored in the same location as the user migration tools you downloaded from the RM Knowledge Library and extracted. In this folder you will find a Logs folder that contains the following log files:

- Move User Data Log_.log this is the full output from the data move tool.

- Robocopy_.log this is a log file of the data copying process.

- Health Check Report_.html



this is the log file from the final step of the data migration process and is available on the Community Connect 4 management server).

When you run the data migration tool it simply performs a copy of the user data – it leaves the student data in its original location on the source server. It may be advisable to leave this data on the server until a time you are confident that all the data has copied successfully. Once you are happy users can access all their files from a Community Connect 4 computer you can delete these files.

Planning the transition to Community Connect 4 from a Community Connect 3 network If you had a Community Connect 3 (CC3) managed network before the addition of the Community Connect 4 (CC4) management server you have the flexibility of still being able to use the Community Connect