What could possibly be worse than having a server on your network crash? How about having every server on your network become inaccessible because of a massive, domain-wide Active Directory failure? As horrifying as a total domain failure may sound, the solution could be just as scary. You may be able to salvage the domain, but, if you can’t, you may have to strip the domain bare, delete the domain, re-create the domain, and finally, add the servers back into the domain. In this Daily Drill Down, I’ll show you how to recover from a domain-level Active Directory failure and hopefully avoid this worst-case scenario.
--------------------------------------------------------------------------------
Back up now before it’s too late
Recovering from a domain-level Active Directory failure is a major undertaking. Therefore, make absolutely certain that you have a good backup of your entire Active Directory before you try any of these techniques.
You should also make sure that you’ve tried every other possible diagnostic and repair technique before attempting to work through any of the techniques that I’m about to discuss. These techniques may solve your problem, but they stand an equal chance of destroying Active Directory totally. But if you’re sure you’re ready, let’s roll the dice.
--------------------------------------------------------------------------------
Trying to save the domain
As you may recall, there are various operations master roles associated with some of the critical Active Directory functions. Some of these roles are forest-based and others are domain-based. A domain can’t function if the domain-level operation master roles are not being performed. Therefore, there’s a chance that rather than having a corrupt Active Directory database, you may simply have a domain controller that’s failing to perform its designated roles.
The first step to recovering from such a problem is to note which servers are performing which roles. You need to make note of the forest-level roles as well as the domain-level roles. The reason for this is that if the forest-level roles are being handled by a domain controller within the failing domain, then you certainly don’t want to do anything to disrupt the servers that are performing the server-level roles. If the forest-level roles are handled by a domain controller within the failing domain and the rest of your domains seem to be functioning correctly, it’s a good indication that you may simply have a domain-level role failure rather than an entire domain failure.
When the entire domain fails, the other domains usually won’t be able to communicate with the failed domain and would therefore also cease to function. You can locate detailed instructions for locating the various server roles in the Daily Drill Down “Understanding Windows 2000 domain controller operations master roles.”
Once you’ve determined which server holds the domain-level operation master roles, try transferring those roles to another domain controller. If no other domain controllers exist within the domain, try temporarily installing a copy of Windows 2000 Server onto a spare PC and making the spare server a domain controller. Then, attempt to transfer the roles to it.
To transfer a role, open Active Directory Users And Computers. Next, right-click on the domain name and select the Connect To Domain Controller command from the resulting context menu. Now, select the domain controller that you want to transfer the role to from the list of domain controllers and click OK. Finally, right-click on the domain name and select the Operations Master command from the context menu.
When you do, you’ll see the Operations Master properties sheet. As you go through each tab on the properties sheet, you’ll see the name of the server that presently holds the designated role and the name of the server that you selected to transfer the role to. To transfer the role, click the Change button. After you’ve transferred each role, click OK to close the properties sheet.
If the domain has serious-enough problems, you may not be able to transfer the roles. If this is the case, you’ll have to seize the roles. The stipulation for doing so is that in order to seize a role, you must take the server that presently holds the roles offline. Once offline, you must never reattach the server to the network or you’ll risk destroying the entire Active Directory. Of course, you can always format the server and bring it back online with a new copy of Windows.
To seize a role, open the command prompt window and enter the following commands:
NTDSUTIL
ROLES
CONNECTIONS
CONNECT TO SERVER servername (where “servername” is the server that you’re going to move the role to)
QUIT
Now, enter one of the following commands to seize the role (the exact command depends on which role you want to seize):
SEIZE INFRASTRUCTURE MASTER
SEIZE RID MASTER
SEIZE PDC
Removing an orphaned domain
Normally, when you use the DCPROMO command to demote a domain controller, the DCPROMO utility will ask you if the domain controller that you’re demoting is the last domain controller in the domain. If it is, then after the demotion is complete, the DCPROMO utility will automatically remove all of the metadata related to the domain from Active Directory.
To sum up, DCPROMO should erase the domain from Active Directory automatically after the last domain controller has been demoted. Unfortunately, things aren’t always this easy. It’s possible for Active Directory corruption or a catastrophic hardware failure to shut down domain controllers without you ever having the chance to demote them. If Active Directory thinks that domain controllers still exist within the domain, then you won’t be able to delete the domain through the usual method. When Active Directory can no longer recognize or interact with a particular domain because of corruption within Active Directory, the domain is said to be “orphaned.”
To remove an orphaned domain, start NTDSUTIL by opening a command prompt, typing NTDSUTIL, and pressing [Enter]. When the NTDSUTIL prompt appears, type METADATA CLEANUP and press [Enter].
Next, connect to the server you’ll be cleaning up by typing CONNECTIONS and pressing [Enter]. Doing so will display the Server Connections prompt. Next, type CONNECT TO SERVER servername where “servername” is the name of the server you’re connecting to. After entering this command, you should see two messages. One of these messages states that NTDSUTIL is binding itself to the specified server using the supplied credentials. The next message confirms the connection.
If you don’t receive these messages, try reentering your credentials using the SET CREDS command and then try the CONNECT TO SERVER command once again. If the command still doesn’t work, check your ability to communicate with the target server.
After you connect to the target server, type QUIT and press [Enter]. This will return you to the METADATA CLEANUP prompt. Next, type SELECT OPERATION TARGET and press [Enter]. This will take you to the SELECT OPERATION TARGET prompt. Next, enter the LIST DOMAINS command. When you do, the NTDSUTIL command will inform you of how many domains it is aware of in the forest and will display each domain and a corresponding number.
Locate the domain that the failing domain controller belongs to and make note of the number that corresponds to it. Now, type SELECT DOMAIN number and press [Enter]. In this command, you should replace the word “number” with the number that corresponds to the domain with which you want to work.
Once you’ve selected the domain, you will see a confirmation message that tells you what domain you are attached to and also informs you that you aren’t presently connected to any specific site or server. This is fine because you are working with a domain-level issue rather than a site-level or a server-level problem. When you get this confirmation message, double- and triple-check to make sure that you’ve selected the correct domain. Otherwise, you could destroy the wrong domain.
When you’re sure that you’re working with the correct domain, enter the QUIT command to return to the METADATA CLEANUP prompt. Finally, type the command REMOVE SELECTED DOMAIN, take a deep breath, and press [Enter]. You should see a confirmation message stating that the domain was deleted.
If you receive an error message, it could be because the domain was already deleted through the natural process or by another administrator. It’s also possible that you could get an error message if Active Directory still contains computer accounts or domain controller accounts. Simply having computer or domain controller accounts present won’t always make the process fail, but I have seen it happen. If you receive such an error, then use the technique that I present in the next section to fix the problem.
You must now complete the process by entering the QUIT command twice, followed by the EXIT command. Remember that you’ve only deleted the reference to the domain from a single domain controller. You must wait for the next replication cycle to complete before the domain will be wiped off of other domain controllers. Once the replication cycle is complete, you’ll be free to begin rebuilding the domain.
Removing orphaned domains that have computer or domain controller accounts present
If my previous technique fails, it could be because computer or domain controller accounts still exist within Active Directory. Normally, you’d use a domain controller within the domain to remove the computer accounts and then do a DCPROMO to demote all of the domain controllers. However, if all of your domain controllers are failing, this may not be an option.
If this is the case, take all of the domain controllers in the failing domain offline. Next, use a domain controller in a different domain to open Active Directory Users And Computers. Remove all of the computer accounts from the failing domain. Remember that since the domain controllers are gone, the computers will never be able to attach to the old domain again once they are removed from Active Directory. You’ll have to reconstruct the domain and then manually reattach the computers to the new version of the domain.
Once you’ve removed all of the computer accounts, you can use the technique in the Daily Drill Down “Picking up the pieces after a failed domain controller demotion” to remove all of the domain controller accounts from the domain. Once you’ve completed this step, you should have no trouble removing the orphaned domain by using the technique that I discussed earlier.
Conclusion
You may be familiar with the saying “We had to destroy the village in order to save it,” the point of which applies to failed domains as well as doomed villages. Recovering from a complete domain failure can be a study in futile rescue efforts. You may be able to save the failed domain, but, if you can’t, you may have to completely destroy and then rebuild the domain that’s damaged. However, by going ahead and destroying the malfunctioning domain, you are cutting out the corruption in Active Directory. Once you’ve removed the corruption, Active Directory will be healthy once again. You’re then free to rebuild the domain.
From: http://articles.techrepublic.com.com/5100-10878_11-1060500.html
Wednesday, June 10, 2009
Tuesday, June 9, 2009
Thursday, June 4, 2009
Application Virtualization "MS App-V" overview
Application Virtualization: If you want to test a new application in a virtual environment, you must first deploy a virtual machine (VM) and install an OS before you can load the application. In the case of Windows OSs, you might also need to purchase an additional license.
Application virtualization started gaining ground with Microsoft’s 2006 purchase of SoftGrid from Softricity. SoftGrid has since been renamed Microsoft Application Virtualization (App-V) and is available as part of "Microsoft Desktop Optimization Pack" (MDOP).
Application virtualization lets software run in a virtualization layer, without the overhead associated with a VM. Microsoft’s App-V client, which comes in varieties for desktops and terminal servers, uses a technology called SystemGuard to sandbox changes that an application would usually make to the registry, file system, and other OS components, and intercepts requests between the application and the virtualized resources. In addition, SystemGuard also isolates virtualized applications from each other.
App-V includes an optional server component that allows the App-V client to stream virtual applications on demand from a server, and run the applications offline (i.e., when disconnected from the server) if necessary. IT departments can sequence programs once and stream them to desktops and terminal servers without having to test for application conflicts. When a program is updated on the App-V server, changes can be streamed automatically to clients. All these factors lead to reduced support, deployment, and patching costs.
Application virtualization started gaining ground with Microsoft’s 2006 purchase of SoftGrid from Softricity. SoftGrid has since been renamed Microsoft Application Virtualization (App-V) and is available as part of "Microsoft Desktop Optimization Pack" (MDOP).
Application virtualization lets software run in a virtualization layer, without the overhead associated with a VM. Microsoft’s App-V client, which comes in varieties for desktops and terminal servers, uses a technology called SystemGuard to sandbox changes that an application would usually make to the registry, file system, and other OS components, and intercepts requests between the application and the virtualized resources. In addition, SystemGuard also isolates virtualized applications from each other.
App-V includes an optional server component that allows the App-V client to stream virtual applications on demand from a server, and run the applications offline (i.e., when disconnected from the server) if necessary. IT departments can sequence programs once and stream them to desktops and terminal servers without having to test for application conflicts. When a program is updated on the App-V server, changes can be streamed automatically to clients. All these factors lead to reduced support, deployment, and patching costs.
Wednesday, June 3, 2009
Blade servers are not 1st choise for server virtualization!!
Blade server market leaders IBM and Hewlett-Packard Co. are both pouring resources in to developing their wares. Most recently, IBM added 10 GigE to its BladeCenter H platform. But, so far, these efforts haven't been enough to convince Rod Lucero, CTO of the Minnesotan VMware consultancy VMPowered, to recommend blade servers to customers undertaking large-scale virtualization and consolidation projects.
Instead, Lucero and his team prefer the standard issue rack-mounted servers. Over the years, he's recommended IBM and Dell, currently favors HP's DL385 and DL585 line, and sees the tide swinging back to IBM with its new quad-core Xeon.
The big problem with blades, Lucero said, is the limited number of network interface cards (NICs) you can attach to a blade -- "two, and that's it," he said, although some newer blade systems are starting to support more.
In rackmount server configuration, VMPowered recommends servers with large numbers of NICs – "never less than six [ports]," Lucero said, and as many 14.
"You really need a lot of I/O to sustain a virtualization infrastructure," he said.
In blades, Fibre Channel and memory capacity are similarly limited relative to rackmount servers.
Not sold on boot-from-SANLucero's other gripe with blades is that they are often sold diskless, thus requiring the blades to boot from SAN – a less-than-perfect process.
For one thing, VMware ESX is very particular about which logical unit number (LUN) it boots from. Also, if you boot from SAN and your SAN crashes, you're stuck. But if the ESX server boots from local disks, it's a relatively easy process to point it to another source of virtual machine images.
In short, boot from SAN "works, but we've seen it be problematic," Lucero said. "We'd certainly never recommend it, especially not with the cost of internal disks today."
Safety in numbersIf you are going to go with blades, you're best off buying them fully populated, Lucero opined, for better negotiating power. Of course, if you do that, you lose one of blade's main selling points – the ability to easily add in more capacity. At the same time though, Lucero said he's often seen companies invest heavily in a sparsely populated blade chassis, only to find that they don't really need the extra capacity down the road.
"Then you have a huge amount of infrastructure that you're not using," he said.
Lucero concedes that a blade chassis does take less power than a comparable rackmount setup. An IBM BladeCenter H, for example, is rated to about 60 amps, while a typical 42U rack requires about 220. But with the consolidation ratios you can get out of hefty rackmount servers, Lucero's not sure it matters. Putting 15 2U servers in a rack, each with two dual cores, could easily give you a consolidation ratio of 20:1, Lucero said – "that's 300 VMs right there!"
Instead, Lucero and his team prefer the standard issue rack-mounted servers. Over the years, he's recommended IBM and Dell, currently favors HP's DL385 and DL585 line, and sees the tide swinging back to IBM with its new quad-core Xeon.
The big problem with blades, Lucero said, is the limited number of network interface cards (NICs) you can attach to a blade -- "two, and that's it," he said, although some newer blade systems are starting to support more.
In rackmount server configuration, VMPowered recommends servers with large numbers of NICs – "never less than six [ports]," Lucero said, and as many 14.
"You really need a lot of I/O to sustain a virtualization infrastructure," he said.
In blades, Fibre Channel and memory capacity are similarly limited relative to rackmount servers.
Not sold on boot-from-SANLucero's other gripe with blades is that they are often sold diskless, thus requiring the blades to boot from SAN – a less-than-perfect process.
For one thing, VMware ESX is very particular about which logical unit number (LUN) it boots from. Also, if you boot from SAN and your SAN crashes, you're stuck. But if the ESX server boots from local disks, it's a relatively easy process to point it to another source of virtual machine images.
In short, boot from SAN "works, but we've seen it be problematic," Lucero said. "We'd certainly never recommend it, especially not with the cost of internal disks today."
Safety in numbersIf you are going to go with blades, you're best off buying them fully populated, Lucero opined, for better negotiating power. Of course, if you do that, you lose one of blade's main selling points – the ability to easily add in more capacity. At the same time though, Lucero said he's often seen companies invest heavily in a sparsely populated blade chassis, only to find that they don't really need the extra capacity down the road.
"Then you have a huge amount of infrastructure that you're not using," he said.
Lucero concedes that a blade chassis does take less power than a comparable rackmount setup. An IBM BladeCenter H, for example, is rated to about 60 amps, while a typical 42U rack requires about 220. But with the consolidation ratios you can get out of hefty rackmount servers, Lucero's not sure it matters. Putting 15 2U servers in a rack, each with two dual cores, could easily give you a consolidation ratio of 20:1, Lucero said – "that's 300 VMs right there!"
APPLICATION VIRTUALIZATION AND STREAMING TIPS
In a new VMware View end-user training environment, complications may arise when previously added applications need to be updated, patched or installed on the original gold template desktop. If a class calls for the availability of multiple versions of the same application, there are only two delivery methods: Deploy two different desktops for each student or introduce application virtualization.
Application virtualization is not a new concept. Citrix has been supplying application streaming for years. VMware ThinApp, Citrix XenApp and Microsoft App-V -- formerly SoftGrid -- are application virtualization providers. While each vendor has its own advantages, this tip focuses specifically on VMware ThinApp application virtualization.
The ThinApp product has three features that benefit the training environment:
ThinApp encapsulates the entire application in a single file -- with no ties into the underlying operating system.
It can deliver the application using various methods such as file share, local directory and email.
It allows linking between multiple applications.
These features create a static desktop environment that allows students to work on multiple versions of one application simultaneously. This classroom environment setup, a "training nirvana" as I call it, saves the trainer a great deal of time when preparing the classroom.
Application delivery methodsWhen using ThinApp for a training environment, the instructor must create a new package containing the application for classroom use. The easiest method to deliver the application to students is to place the package on a file share that's accessible to all desktops. If the file share is used as the delivery mechanism, there is no need to rollout a new set of desktops -- except when a new version of the OS is required or a patch is needed.
The other method of delivery involves installing the application package on each desktop. This process can be completed by using ThinApp's Update Management feature. The ThinApp package contains a small piece of code that contacts the ThinApp server every time the application is started. New application patches can then be streamed to the package. This method is useful for training situations in which the application package is required on the desktop.
Application virtualization is not a new concept. Citrix has been supplying application streaming for years. VMware ThinApp, Citrix XenApp and Microsoft App-V -- formerly SoftGrid -- are application virtualization providers. While each vendor has its own advantages, this tip focuses specifically on VMware ThinApp application virtualization.
The ThinApp product has three features that benefit the training environment:
ThinApp encapsulates the entire application in a single file -- with no ties into the underlying operating system.
It can deliver the application using various methods such as file share, local directory and email.
It allows linking between multiple applications.
These features create a static desktop environment that allows students to work on multiple versions of one application simultaneously. This classroom environment setup, a "training nirvana" as I call it, saves the trainer a great deal of time when preparing the classroom.
Application delivery methodsWhen using ThinApp for a training environment, the instructor must create a new package containing the application for classroom use. The easiest method to deliver the application to students is to place the package on a file share that's accessible to all desktops. If the file share is used as the delivery mechanism, there is no need to rollout a new set of desktops -- except when a new version of the OS is required or a patch is needed.
The other method of delivery involves installing the application package on each desktop. This process can be completed by using ThinApp's Update Management feature. The ThinApp package contains a small piece of code that contacts the ThinApp server every time the application is started. New application patches can then be streamed to the package. This method is useful for training situations in which the application package is required on the desktop.
Desktop Virtualization!!! (Pretty basic)
What exactly is desktop virtualization?
Desktop virtualization is the running of desktop operating systems in a virtualized environment. Products like Microsoft Virtual PC, VMware Workstation and Parallels Desktop for Mac are all examples of tools that virtualize the desktop for users and present an isolated operating system. Desktop virtualization decouples the physical machine from the software.
What is Virtual Desktop Infrastructure?
Virtual Desktop Infrastructure (VDI) is the use of virtualization to run desktops in a data center. The desktop is delivered to the user on demand and managed centrally, and it delivers the same user experience as a standard PC.
What is the main difference between desktop virtualization and VDI?
Desktop virtualization focuses on delivering a second operating system experience to the user, complete with GUI and an obvious separation of layers. VDI delivers a familiar desktop experience to the user while still separating the physical hardware from the environment.
When would it make sense to use desktop virtualization?
Desktop virtualization makes sense when users need a different capability for the software they have deployed. For example, a user who needs to run an older version of certain software would use desktop virtualization. Desktop virtualization provides many of the key benefits of a terminal server with added flexibility.
When would it make sense to use VDI?
VDI should be used when the user needs to be sheltered from the virtualization layer and the administrators wish to have central administration of services. For example, the need to centrally roll out desktops or offer desktops both in the office and remotely may lead to VDI implementation.
How can solution providers build a service offering around desktop virtualization?
Like many services, you can focus on projects as well as recurring revenue opportunities. Project offerings include setup and configuration of both desktop virtualization and VDI systems, enabling users to have virtualized environments. Service providers can also elect to deliver these systems as a solution, either on premise or as a cloud-based service, and offer this on a monthly recurring basis.
What pitfalls are there when implementing desktop virtualization?
As with any virtualization solution, adding a virtualization layer introduces a level of complexity to the system. The risk is in not understanding how to correctly deploy and manage both types of offerings.
How should desktop virtualization be managed?
Desktop virtualization should be managed like any IT system -- by taking into account all of the components of the solution. This includes the hardware, software and virtualization layers. You should ensure that all layers are monitored so that they can be managed.
When should we not use desktop virtualization?
Desktop virtualization should not be used in situations where the application requires direct access to the hardware layer. In these cases, virtualization would be inappropriate and another technology approach must be determined.
Subscribe to:
Posts (Atom)