10 Steps to Prepare for NT 5.0 Now

Take action today and meet Windows NT 5.0 halfway

Anxiously awaiting Windows NT 5.0? By now you're probably intrigued by the rich and impressive features this new version of NT promises: the Active Directory (AD), the incorporation of Windows-based Terminal Server (formerly code-named Hydra), 64-bit Very Large Memory (VLM), IntelliMirror, the Microsoft Management Console (MMC), Plug and Play, and Windows Driver Model (WDM) support, to name a few. Perhaps you're assuming that, as in the past, Microsoft will make the migration process easy and painless: You'll just buy the software, install it, and be on your way rejoicing. If that's your fantasy, think again.

Because the next version of NT promises to be as revolutionary as it is evolutionary, the new technologies will affect your network and your life as an administrator in several ways. To begin, you'll need to do more planning for NT 5.0 than for any previous upgrade. Fortunately, you can start today to prepare for your migration to 5.0. This article will discuss several NT 5.0 migration issues and recommend specific steps you can take to be ready for NT 5.0 when it arrives.

Prepare Your Domain Structure for AD
The most important aspect of the NT 5.0 rollout is the migration of your existing domain structure to NT 5.0's AD. The complexity of this process depends on your network's architecture. If you have a single-domain model (perhaps with local Backup Domain Controllers--BDCs--at remote sites for quicker logons and access to local network resources), the process of migrating to AD will be fairly straightforward, and AD will give you new options for further optimizing the administrative structure and network traffic of your existing domain model. But if you've implemented a complex multidomain model with decentralized administration, your planning process will be more involved.

Because of the limitations of NT 3.x and 4.0 domain architecture, many organizations have implemented multidomain models that use centralized administration (e.g., master domain or multiple master domain models) and centralized account domains with remote-resource domains. Such designs may fit an organization's administrative structure, particularly if IS staff are in one central location. But in other organizations, this design does not fit administrative structure. Those organizations implement multidomain models more to avoid complete-trust models (with their inherent multiple one-way trust relationships and resulting administrative burden) than to accommodate the needs of the organization.

NT 5.0 will change this complexity. An organization will be able to choose from a wide variety of multitiered network designs that it can fashion around any number of criteria, such as its organizational model, geographical layout, or a combination of the two. Furthermore, if you've had to create master or multimaster domain models to minimize the administrative hassles of placing user accounts into multiple domains, AD will let you move those accounts safely back to the domains in which they belong.

Granularity is the key. NT 5.0 enables these possibilities because of its granular design. NT 3.x and 4.0 group administrative entities (e.g., Administrators, Server Operators, and Backup Operators) into a limited number of global groups with a generic set of administrative rights, but AD will let you set administrative rights down to the individual permission level. This structure means you can easily assign user accounts in particular domains the amount of access they require to administer their local office, and you can do so without compromising the overall security or design of your network. You no longer have to choose between administering these resources remotely or assigning second-level administrators into a limited set of stock account groups.

AD's granularity has benefits that extend into other areas of administrative life. For example, you can use AD to assign particular user or group permissions to particular applications, as well as to traditional resources such as file and print shares. The ability to assign permissions to applications is leveraged by Zero Administration Kit (ZAK), a preview of Zero Administration for Windows (ZAW) that is available now. (For more information about ZAK and ZAW, see "Related Articles In Windows NT Magazine" on page 114.) By breaking permissions and rights down to a more detailed level, AD lets you tailor your directory to fit your organization's structure and administrative requirements.

Preparing for life in AD. What can you do now to prepare for life in AD? If you administer a multidomain environment, consider the advantages of flattening (i.e., consolidating and reducing) your multidomain structure before the arrival of NT 5.0. Flattening your structure will make room for a simplified AD design, and you can undo some of the kludges you may have been forced to introduce into your network design to accommodate your organization's administrative needs. I know what you're thinking: Won't that step mean reinstalling domain controllers? Believe it or not, it doesn't have to.

FastLane Technologies has designed an impressive new product named Phoenix. This domain reconfiguration tool performs the feat of automating migration of user, group, and computer accounts from one domain into another. Automating migration lets you migrate a multiple-domain environment into a single- or multiple-master environment in either a piecemeal or wholesale fashion. Phoenix's six-stage migration process systematically copies the user account, global group, local group, access control lists (ACLs), user rights, and computer accounts from the source domain into a target domain. When the migration is complete, users can log on to the new domain without even knowing that their accounts were moved. If problems come up during the transition, however, users can log on to the source domain, because Phoenix has copied the information--it hasn't merely moved the information. (Screen 1 shows Phoenix's main display.)

Phoenix is impressive and could prove invaluable if you want to simplify your organization's domain structure before an NT 5.0 migration. For additional information on Phoenix, check out FastLane's Web site (http://www.fastlanetech.com).

To facilitate the flattening process, AD contains an important new feature, the Organizational Unit (OU), that makes categorizing your organization easy, even within a single domain. You can subdivide your organization into OUs in any way you want and later promote each OU to a full-blown domain within your organization's namespace--all with little or no effect on the users or resources within the OU. When you use the OU feature, you don't have to create multiple domains to divide your organization into separate, logical subdivisions.

Keep in mind that although domain flattening may be appropriate for some organizations, it isn't appropriate for all organizations. For example, if you want to separate your organization's divisions into separate domains under AD, you will want to retain your existing master or multiple-master domain structure until migration. Another reason for you to retain your existing domain structure as you migrate to NT 5.0 is that AD supports transitive trusts. In a transitive trust, the established trust (domain A trusts domain B and domain B trusts domain C) also means that domain A trusts domain C (see Figure 1 for an illustration of this trust arrangement). NT 3.x and 4.0 did not support transitive trusts; thus administrators were required to create additional trust relationships to establish a relationship between domains not related through established trusts. Obviously, you'll have fewer headaches creating multidomain security relationships under NT 5.0 than you're experiencing with NT 3.x and 4.0.

Finally, NT 5.0 can migrate any domain structure you have established, so flattening will not be necessary unless it will benefit your AD architecture. But remember that if you analyze your existing domain structure and compare it to what you might want to implement later under NT 5.0, you can start planning an effective and appropriate directory structure for your organization today. If you decide to modify your domain structure before your NT 5.0 migration and want to minimize the effects of a change in domain architecture on your users, consider implementing the modifications immediately before you introduce NT 5.0. Then you won't have to deal with a problem-filled interim period between the flattening process and the arrival of NT 5.0.

The forest for the trees. NT 5.0's AD design integrates the concepts of forests and trees (for details, see "Related Articles in Windows NT Magazine," page 114). A tree is a group of NT domains in AD that form a contiguous namespace and share a schema. For example, assume a domain named bigcorp.com exists in your AD structure. The two subdivisions of bigcorp.com are europe and us, and us has a subdivision called sales. Within AD, the names of these domains would be europe.bigcorp.com, us.bigcorp.com, and sales.us.bigcorp.com. This arrangement demonstrates the hierarchical structure of AD and its namespace: These domains are all part of one contiguous, related namespace in the directory; that is, they form one domain tree. The name of the tree is the root level of the tree: In this case, bigcorp.com. See Figure 2 for an illustration of this single-domain tree.

Let's take this concept to the next level. Assume that, within your AD, a parent organization oversees bigcorp, and this parent organization owns another subsidiary, called bigbiz, which is listed in AD with bigcorp. One subdivision, us.bigbiz.com, is beneath bigbiz in AD. Although your company wants both bigcorp and bigbiz defined in the same AD for administrative reasons, you don't want them to share a namespace. So, you define bigcorp and bigbiz as separate trees within the same forest (see Figure 3, page 111, for an illustration of this arrangement). All trees in a forest share a schema, configuration, and Global Catalog. Furthermore, all trees in a forest trust one another because of the transitive, hierarchical Kerberos trust relationships that AD is structured on.

To plan your organization's AD structure and namespace effectively, you can read two Microsoft white papers: "Migrating from Microsoft Windows NT Server 4.0 to Windows NT Server 5.0," and "Windows NT 5.0 Namespace Design." Both papers and others relating to NT 5.0 migration issues are available on Microsoft's Web site (http://www.microsoft.com/ntserver/guide/nt5_pdcwp.asp).

Action Plan:

  • Learn about AD, and download the Microsoft NT 5.0 white papers.
  • Start planning your AD structure.
  • If appropriate, flatten and consolidate your domain structure.

Standardize Your Network on TCP/IP
TCP/IP is the future of networking, and it has become the network protocol of choice for NT 5.0 because it provides a uniform platform that supports many different operating systems. TCP/IP is the only protocol NT 5.0 installs by default during clean installations (legacy environments may still implement NetBEUI and IPX/SPX). This situation means that one of the best things you can do to prepare your organization for NT 5.0 is to standardize on TCP/IP as your primary (preferably sole) network protocol. Standardizing on TCP/IP as your primary network protocol will give you an additional benefit: Because TCP/IP is a highly efficient, routable protocol, you won't hit the types of bandwidth and usability ceilings that occur with NetBEUI (which is nonroutable) and IPX/SPX (which, although it's routable, has higher overhead than TCP/IP in WAN environments).

If you haven't already implemented TCP/IP on your network but will do so before your NT 5.0 migration, you must address NetBIOS-to-IP address-name-resolution issues. You can address these issues by deploying either Windows Internet Naming Service (WINS) or Domain Name System (DNS) servers (I'll discuss DNS servers in Step 3) or by using a centralized LMHOSTS file to resolve names. In addition, if your network is connected to the Internet, you must create an appropriate firewall to protect the network against intruders.

Get on the TCP/IP bandwagon now rather than later. TCP/IP can be slightly more difficult to administer than NetBEUI and IPX/SPX, so if you don't have much experience with TCP/IP, begin now to learn about TCP/IP administration. One helpful tool is Microsoft TCP/IP Training (Microsoft Press), a training kit published in July 1997. It's one of many TCP/IP training resources from Microsoft Press. You can find more information about these resources at the Microsoft Press Web site (http://mspress.microsoft.com).

Action Plan:

  • Learn about TCP/IP routing and administration issues.
  • If you use routable IP addresses, ob-tain an IP address pool from your Internet Service Provider (ISP). If you use nonroutable addresses (e.g., 10.x.x.x, 192.168.x.x, 172.16.x.x, 172.31.x.x), this step isn't necessary.
  • Deploy TCP/IP as the primary file and print service protocol within your organization now. If possible, make TCP/IP your sole network protocol to minimize protocol overhead and administrative problems on the network.

Learn the Ways of DNS
Name resolution is central to TCP/IP standardization and deployment. Most current TCP/IP-based NT networks use WINS servers or LMHOSTS files to resolve NetBIOS names to IP addresses. But in NT 5.0, you query AD to resolve names. AD uses a dynamic form of traditional DNS that offers NT networks the best of both DNS and WINS.

In NT 5.0, Dynamic Host Configuration Protocol (DHCP) servers automatically register clients in AD's DNScompliant namespace and automatically unregister them when the DHCP lease expires or is released. As a result, you don't need to manually maintain dynamic DNS zone files, as you do with traditional DNS. Furthermore, dynamic DNS delivers a name-resolution method that is far more scalable and robust than WINS.

Another nicety of the dynamic DNS design is that it unifies the local and global namespaces of Internet-connected NT networks into a single uniform environment. With NT 5.0, you won't have to run two different name-resolution methods on your network, because everything's DNS. Finally, NT's dynamic DNS namespace is automatically stored within and therefore replicated throughout AD, and the consistency that this approach establishes means your DNS namespace will have a level of fault tolerance.

To facilitate your migration to NT 5.0's DNS environment, begin verifying that existing computer and network names within your organization are DNS-friendly. DNS stipulates that domain and host names contain only the following characters: A-Z, a-z, 0-9, and - (hyphen), with no spaces or underscoring. If a domain or a host is using names that don't follow the DNS convention, change the names so that they conform. In the case of workstations, this step probably won't be a big deal. However, in the case of domains or servers, illegal names will have an impact and will require a bit more planning on your part.

Work with the InterNIC (the Internet's name assignment authority) or an ISP to obtain a domain name for your organization if you don't have one (e.g., abc-corp.com, somegroup.org), whether you're connected to the Internet now or not (contact InterNIC at http://rs.internic.net). This task is important because when you migrate to NT 5.0, your AD structure will drive your DNS naming structure. If you have developed a naming structure for your organization that does not conform to DNS standards and you later connect to the Internet, you will have to observe Internet DNS standards and use a name that another organization hasn't already taken. Then you'll have to go through the hassle of renaming your entire organization and all of its domain trees. You can ensure that this hassle doesn't happen by registering DNS domain names for your organization now that will work later if you decide to connect to the Internet. And by acting now, you'll have a better chance of getting the domain name you want for your organization. If you wait, someone else might take the name you prefer.

Here's a final important note: You can run separate internal and external DNS namespaces for your organization; you don't have to use one shared internal/external namespace. For example, you might want to run one namespace outside a firewall for Internet users and another inside the firewall for internal company users. Running two namespaces has associated problems and security considerations. For more information, read the Microsoft white paper, "Windows NT 5.0 Namespace Design" (http://www.microsoft.com/ntserver/guide/nt5_pdcwp.asp).

Action Plan:

  • Learn about DNS and how it works. One excellent source of DNS information is the book DNS and BIND, by Paul Albitz and Cricket Liu (O'Reilly & Associates).
  • Obtain a domain name (or multiple domain names, if necessary) for your organization. You can register domain names directly with the InterNIC or through an ISP. For your domain name, you will pay one initial registration fee and a yearly maintenance fee.
  • Begin the process of ensuring that all of your current machine and domain names are DNS friendly.
  • If you don't have a DNS server, deploy one in a test environment so that you can become familiar with DNS structure and management.

Download and Install the NT 4.0 Option Pack
If you're a developer or an ISP and want to develop applications that use the technologies Microsoft provides in Microsoft Message Queue Server (MMQS) and Microsoft's Transaction Server (MTS), the NT 4.0 Option Pack is for you (see Ken Spencer, "The NT 4.0 Option Pack," January 1998). The Option Pack is a downloadable set of operating system updates for NT Workstation 4.0 and NT Server 4.0 that installs several updated services and components (there is a version for Windows 95). For example, the Server component of the Option Pack includes IIS 4.0, MTS 2.0 (see "Re-lated Articles in Windows NT Magazine" on page 114), an updated version of Remote Access Service (RAS), Microsoft Index Server 2.0, Microsoft Certificate Server 1.0, MMQS 1.0, Internet Explorer (IE) 4.0, and NT Service Pack (SP) 3. The Workstation component of the Option Pack updates Peer Web Services to the latest (IIS 4.0-compatible) version, updates the system to SP3, and installs client components for the latest version of RAS, MTS, and MMQS.

Because these services are advance releases of NT 5.0 services, you can move a step toward NT 5.0 by downloading the Option Pack now. For more information and to download the NT 4.0 Option Pack, visit Microsoft's Option Pack Web site (http://backoffice.microsoft.com/downtrial/moreinfo/whatisntop.asp).

Action Plan:

  • Download and install the NT 4.0 Option Pack from Microsoft's Web site.

Get Rid of the SID Skeletons in Your Closet
A unique 32-bit security identifier (SID) number represents every NT computer in a domain (and such entities as the domain itself and user and group accounts). When you install NT, it automatically assigns the machine a globally unique SID. However, disk-duplication utilities bypass the SID assignment process when you use them to clone NT installations: The cloned systems use the source system's SID. Many organizations have used the cloning method to speed the process of installing NT onto workstations and servers.

Although cloning doesn't cause problems under NT 3.x or 4.0, it probably will under NT 5.0. This likelihood is because AD uses the SID to identify a particular system within the directory. Therefore, if multiple machines use the same SID, confusion and problems will result. Microsoft has waffled a bit on exactly how cloning will affect networks under NT 5.0. Stay on the safe side, and don't practice cloning to install NT in your environment. If you must have some duplication, duplicate after the text-mode portion of setup, before the GUI-mode portion begins. At this stage of the installation process, no SID will have been assigned. Duplicating your system after the text-mode portion of the setup doesn't produce system cloning as exact as that of a full duplication of a customized and integrated NT installation. However, this method doesn't risk the potential problems of SID duplication. You can minimize legwork in NT installations by using automation components such as customized unattend.txt files and the sysdiff.exe utility.

Another solution to the system duplication problem has recently appeared. PowerQuest announced a new product, SIDchanger, that automatically changes the SIDs and computer names of duplicated NT computers to unique numbers. SIDchanger is available free to registered users of PowerQuest's DriveImage Professional drive duplication utility: Download it from PowerQuest's Web site (http://www.powerquest.com). At almost the same time, Ghost Software announced that it has developed a similar utility, GHOST Walker. Like SIDchanger, GHOST Walker ensures SID uniqueness on duplicated workstations. Both utilities work by changing all textual and binary references to a particular system's SID in the Registry to make that system unique on the network. If you're a registered owner of GHOST Professional, you can download a free copy of GHOST Walker from the Ghost Software Web site (http://www.ghostsoft.com). Another freeware SID-changing utility is Mark Russinovich and Bryce Cogswell's NTSID. For more information on NTSID, visit the NT Utilities Web site (http://internals.com/ntutil.htm).

Action Plan:

  • Verify the uniqueness of the SIDs on all the NT computers in your organization. If you find duplications, obtain a SID-replacement utility and use it before your migration to NT 5.0.


Beef Up the Budget for PC Upgrades Most seasoned NT users will not be surprised to learn that the new technologies in NT 5.0 are likely to add to the price tag for system resource requirements. The base recommended memory configuration for NT 5.0 is 64MB for workstations (it's more like 96MB for servers). If you're keeping score, this requirement is about three times the minimum recommended configuration for a comparable NT 4.0 system. The disk space requirements will probably see similar increases.

Although you aren't obliged to install NT 5.0 on every workstation and server on your network, you probably will want to migrate as many machines as possible to NT 5.0. If so, start budgeting now for bringing all your target NT 5.0 machines up to the baseline NT 5.0 configuration. To reach the baseline, a computer must be a Pentium-based (preferably Pentium Pro or Pentium II) system with at least 64MB of RAM and a 2GB hard disk. You don't need 2GB to install NT, but 2GB is a realistic number for a hard disk that will hold the operating system, local profiles and application support files, and whatever data users might store locally. On a server, don't think of installing NT 5.0 on anything less than a Pentium Pro system with 128MB of RAM, and as always, be sure to use a SCSI-based disk subsystem to minimize CPU utilization and maximize performance.

Action Plan:

  • Plan for your baseline NT 5.0 Workstation and Server configurations, and begin budgeting for and installing the upgrades you require to deploy NT 5.0 on your network. Be sure you understand all the features you'll be using in NT 5.0 and how each might affect the system resource requirements of your servers and workstations.

Obtain the NT 5.0 Beta and Set Up a Lab Environment
One of the most important steps you can take to prepare for NT 5.0 is to start using it now. You can do so by becoming part of the NT 5.0 beta program--there's no substitute for the advanced knowledge you'll gain through experience. Learn about the NT 5.0 beta program from the NT 5.0 beta Web site (http://ntbeta.microsoft.com).

Once you've joined the beta program, you'll have access to another invaluable source of NT 5.0 information: Microsoft NT 5.0 beta newsgroups. Several very active newsgroups are already available to NT 5.0 beta program participants. Each newsgroup focuses on a different component of NT 5.0. (To get more information about NT 5.0 newsgroups, check out the following Web site: http://premium.microsoft.com/support/ntserver/nt5betanews.asp. This page lists NT 5.0 newsgroups and provides links to each.)

Action Plan:

  • Join the NT 5.0 beta program and begin installing and using NT 5.0 beta in a test environment with your applications.

Start Using ZAK Now
The concept of total cost of ownership (TCO) has become an important issue in the industry, and Microsoft has responded by developing ZAW, a set of core technologies to make the administration and control of user workstations simpler and more automatic. The first phase of ZAW is available now in ZAK for NT 4.0 and Windows 95.

ZAK presents numerous important features that Microsoft will fully integrate into NT 5.0. These features will be managed in NT 5.0 through an MMC snap-in. However, you don't have to wait until NT 5.0 ships to reap the benefits of these new features--you can download ZAK from Microsoft's Web site (http://crosoft.com/windows/zak) right now. When you do so, you'll benefit immediately from the features that are available, and you'll get a preview of the innovative technology coming in NT 5.0. You'll find a link to download a ZAK self-paced training kit for NT Workstation 4.0 that will introduce you to ZAK's features and give you helpful deployment hints.

Action Plan:

  • Download ZAK for NT 4.0 and Win95 and start learning about ZAK's features. You can also download the self-paced ZAK training kit.

Obtain an Object Identifier for Your Organization
One of the best things about NT 5.0's AD is its extensible schema. This feature means you are free to customize your AD structure by defining new object classes and attributes that you can store inside the directory. This feature is extremely important for developers and administrators, because it will let them tailor their AD structure to their organizations' needs and extend the structure to incorporate new information and network services. A special management snap-in for the MMC comes with NT 5.0 to facilitate management of AD's schema.

One gotcha with schema extensions is that you must acquire a special number called an Object Identifier (OID) for each new attribute or class you define. An OID is an assigned number that identifies an object class or attribute within AD. Like IP addresses and DNS namespaces, OIDs are assigned by issuing authorities within a country. In the US, the issuing authority for OIDs is ANSI.

An OID is in the form of a dotted decimal string (e.g., Organizations and individuals obtain a root OID from the issuing authority in their country, then divide the assigned OID into additional branch OIDs for use within their directories. For example, Microsoft has a root OID of 1.2.840.113556, which the company has broken down into multiple branch OIDs (one to allocate OIDs for AD classes, another for AD attributes, and so on) for different uses within AD.

You can apply now for your organization's OID, which will save you time later, when you'll be busy migrating your entire network to NT 5.0. Send an email request to ANSI at [email protected]

Action Plan:

  • Obtain your organization's root OID from ANSI. You pay a fee for obtaining a root OID.

Plan for a NetBIOS-free Planet
Believe it or not, NT 5.0 is designed to free you from the bondage of NetBIOS. Because AD uses a DNS-based naming architecture rather than a NetBIOS-based one, NT 5.0 theoretically can let you have zero NetBIOS traffic running on your network. For TCP/IP purists and those of us who hate the load NetBIOS traffic places on our networks, this possibility is welcome indeed. However, eliminating NetBIOS from your network won't be as easy as it sounds. Many, if not most, current Windows utilities and applications rely on a NetBIOS API layer to function (e.g., even simple NT NET commands require NetBIOS).

To completely remove NetBIOS from your network, you must first eliminate all machines that use NetBIOS naming (which means they must join the NT 5.0 network as AD participants) and all applications that require NetBIOS. Don't pull the plug on NetBIOS until you've thoroughly explored the ramifications of doing so in a test environment using your existing applications. The good news is that you can continue to run NetBIOS on your NT 5.0 network until you've upgraded all your clients to use AD, and until you've eliminated all NetBIOS-based applications.

Action Plan:

  • Begin removing NetBIOS-dependent applications and operating systems (such as Windows for Workgroups) from your network. Replace your legacy NetBIOS applications and utilities with AD-enabled ones as they become available. Although you don't have to remove NetBIOS to deploy NT 5.0, doing so will create a more efficient network environment, and one that leverages AD more effectively.

And Keep in Mind
If you follow the steps I've outlined, your company's migration to NT 5.0 will be about as smooth as anyone can make it. Here are some additional pointers to help you move easily to NT 5.0. First, Microsoft recommends that you install or continue to run WINS throughout the NT 5.0 migration process. According to Microsoft, running WINS during your migration will make it go much more smoothly. Once you've upgraded all your domain controllers, resource servers, and workstations, you can safely remove WINS.

Second, do at least one complete dry-run migration before your live deployment of NT 5.0. A good way to do this dry run is to create a test environment that duplicates as closely as possible your network environment. For example, you can restore a backup of your domain controllers onto test machines and set up an array of test workstations to represent your user workstations. Then perform a sample migration and create your AD structure. If you're running in a WAN-based environment, obtain some figures on the total bandwidth utilization of your new network to compare it with your previous configuration (and to ensure that you haven't exceeded the capacity of your links). You can do this checking with Performance Monitor or a network-monitoring utility such as the Network Monitor, which comes with Microsoft Systems Management Server (SMS). Although NT 5.0 should create less traffic on WAN links than earlier versions of NT did, if you run a mixed NT 5.0 and 4.0 domain environment you may increase the overall bandwidth utilization on your network--a situation you'll want to watch out for.

Finally, keep up to date with all the changes that occur during the development of NT 5.0, from now until its final release date. One lesson I've learned from previous Microsoft beta cycles is that new features or product revelations can appear out of nowhere. Such is life in the brave new world of NT evolution.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.