Monthly Archives: September 2015

Using the BurFlags registry key to reinitialize File Replication Service replica sets

Posted on by

https://support.microsoft.com/en-us/kb/290762

 

Restoring FRS replicas

The global BurFlags registry key contains REG_DWORD values, and is located in the following location in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

The most common values for the BurFlags registry key are:

  • D2, also known as a nonauthoritative mode restore
  • D4, also known as an authoritative mode restore

You can also perform BurFlags restores at the same time as you restore data from backup or from any other known good source, and then restart the service.

Nonauthoritative restore

Nonauthoritative restores are the most common way to reinitialize individual members of FRS replica sets that are having difficulty. These difficulties may include:

  • Assertions in the FRS service
  • Corruption of the local jet database
  • Journal wrap errors
  • FRS replication failures

Attempt nonauthoritative restores only after you discover FRS dependencies and you understand and resolve the root cause. For more information about how to discover FRS dependencies, see the “Considerations before configuring authoritative or nonauthoritative restores of FRS members” section later in this article.

Members who are nonauthoritatively restored must have inbound connections from operational upstream partners where you are performing Active Directory and FRS replication. In a large replica set that has at least one known good replica member, you can recover all the remaining replica members by using a nonauthoritative mode restore if you reinitialize the computers in direct replication partner order.

If you determine that you must complete a nonauthoritative restore to return a member back into service, save as much state from that member and from the direct replication partner in the direction that replication is not working. This permits you to review the problem later. You can obtain state information from the FRS and System logs in the Event Viewer.

Note You can configure the FRS logs to record detailed debugging entries. For more information about how to configure FRS logging, click the following article number to view the article in the Microsoft Knowledge Base:

221111 Description of FRS entries in the registry

To perform a nonauthoritative restore, stop the FRS service, configure the

BurFlags

registry key, and then restart the FRS service. To do so:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. Locate the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  7. In the right pane, double-click BurFlags.
  8. In the Edit DWORD Value dialog box, type D2 and then click OK.
  9. Quit Registry Editor, and then switch to the Command box.
  10. In the Command box, type net start ntfrs.
  11. Quit the Command box.

When the FRS service restarts, the following actions occur:

  • The value for BurFlags registry key returns to 0.
  • Files in the reinitialized FRS folders are moved to a Pre-existing folder.
  • An event 13565 is logged to signal that a nonauthoritative restore is started.
  • The FRS database is rebuilt.
  • The member performs an initial join of the replica set from an upstream partner or from the computer that is specified in the Replica Set Parent registry key if a parent has been specified for SYSVOL replica sets.
  • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

Note: The placement of files in the Pre-existing folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. Any files destined for the replica that exist only in the local Pre-existing folder and did not replicate in after the initial replication may then be copied to the appropriate folder. When outbound replication has occurred, delete files in the Pre-existing folder to free up additional drive space.

Authoritative FRS restore

Use authoritative restores only as a final option, such as in the case of directory collisions.

For example, you may require an authoritative restore if you must recover an FRS replica set where replication has completely stopped and requires a rebuild from scratch.

The following list of requirements must be met when before you perform an authoritative FRS restore:

  1. The FRS service must be disabled on all downstream partners (direct and transitive) for the reinitialized replica sets before you restart the FRS service when the authoritative restore has been configured to occur.
  2. Events 13553 and 13516 have been logged in the FRS event log. These events indicate that the membership to the replica set has been established on the computer that is configured for the authoritative restore.
  3. The computer that is configured for the authoritative restore is configured to be authoritative for all the data that you want to replicate to replica set members. This is not the case if you are performing a join on an empty directory. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    266679 Pre-staging the File Replication service replicated files on SYSVOL and Distributed file system shares for optimal synchronization
  4. All other partners in the replica set must be reinitialized with a nonauthoritative restore.

To complete an authoritative restore, stop the FRS service, configure the

BurFlags

registry key, and then restart the FRS service. To do so:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. Locate the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  7. In the right pane, double click BurFlags.
  8. In the Edit DWORD Value dialog box, type D4 and then click OK.
  9. Quit Registry Editor, and then switch to the Command box.
  10. In the Command box, type net start ntfrs.
  11. Quit the Command box.

When the FRS service is restarted, the following actions occur:

  • The value for the BurFlags registry key is set back to 0.
  • An event 13566 is logged to signal that an authoritative restore is started.
  • Files in the reinitialized FRS replicated directories remain unchanged and become authoritative on direct replication. Additionally, the files become indirect replication partners through transitive replication.
  • The FRS database is rebuilt based on current file inventory.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

Global vs. replica set specific reinitialization

There are both global- and replica set-specific BurFlags registry keys. Setting the global BurFlags registry key reinitializes all replica sets that the member holds. Do this only when the computer holds only one replica set, or when the replica sets that it holds are relatively small.

In contrast to configuring the global BurFlags key, the replica set BurFlags key permits you to reinitializes discrete, individual replica sets, allowing healthy replication sets to be left intact.

The global BurFlags registry key is found in the following location in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup / Restore\Process At Startup

This key can contain the same values as those that are discussed earlier in this article for authoritative and nonauthoritative restores.

You can locate the replica set specific BurFlags registry key by determining the GUID for the replica set that you want to configure. To determine which GUID corresponds to which replica set and configure a restore, follow these steps:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. To determine the GUID that represents the replica set that you want to configure, follow these steps:
    1. Locate the following key in the registry:
      KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
    2. Below the Replica Sets subkey, there are one or more subkeys that are identified by a GUID. In the left pane, click the GUID, and then in the right pane note the Data that is listed for the Replica Set Root value. This file system path will indicate which replica set is represented by this GUID.
    3. Repeat step 4 for each GUID that is listed below the Replica Sets subkey until you locate the replica set that you want to configure. Note the GUID.
  7. Locate the following key in the registry:
    KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets
  8. Below the Cumulative Replica Sets subkey, locate the GUID you noted in step 6c.
  9. In the right pane, double click BurFlags.
  10. In the Edit DWORD Value dialog box, type D2 to complete a nonauthoritative restore or type D4 to complete an authoritative restore, and then click OK.
  11. Quit Registry Editor, and then switch to the Command box.
  12. In the Command box, type net start ntfrs.
  13. Quit the Command box.

Considerations before you configure authoritative or nonauthoritative restores of FRS members

If you configure an FRS member to complete an authoritative or nonauthoritative restore by using the BurFlags registry subkey, you do not resolve the issues that initially caused the replication problem. If you cannot determine the cause of the replication difficulties, the members will typically revert back to the problematic situation as replication continues.

A detailed breakdown on FRS interdependencies is beyond the scope of this article, but your troubleshooting should include the following actions:

  • Verify that Active Directory replication is successful. Resolve Active Directory replication issues before you perform additional FRS troubleshooting. Use the Repadmin /showreps command to verify that Active Directory replication is occurring successfully. The Repadmin.exe tool is located in the Support\Tools folder on the Windows 2000 CD-ROM.
  • Verify that inbound and outbound Active Directory replication occurs between all domain controllers that host SYSVOL replica sets and between all domain controllers that host computer accounts for servers that participate in DFS replica sets.
  • Verify that FRS member objects, subscriber objects and connection objects exist in the Active Directory for all the computers that participate in FRS replication.
  • Verify that inbound and outbound connection objects exist for all domain controllers in the domain for SYSVOL replica sets.
  • Verify that all the members of DFS replica sets have at least inbound connection objects in a topology to avoid islands of replication.
  • Review the FRS and SYSTEM event logs on direct replication partners that are having difficulty.
  • Review the FRS debug logs in the %SYSTEMROOT%\DEBUG\NTFRS_*.LOG between the direct replication partners that are having replication problems.

Install SQL 2012 on Core

Posted on by

To install Microsoft SQL 2012 on a Microsoft 2012 core edition, use the /UIMODE switch. This will bring op the old interface.

setup /UIMODE=EnableUIonServerCore

 

2725_xxxx_2

 

Other samples to install it through the command line (parameters or file) can be found on: https://www.mssqltips.com/sqlservertip/2725/installing-sql-server-2012-on-windows-server-core-part-3/

Planning the XenApp Data Store

Posted on by

http://support.citrix.com/proddocs/topic/xenapp65-planning/ps-planning-datastore-intro-v2.html?_ga=1.50490985.1747981757.1428398346

 

Planning the XenApp Data Store

Updated: 2015-04-02

When you deploy your server farm, it must have an associated data store. When servers in a farm come online, they query the data store for configuration information. The data store provides a repository of persistent information, including:

  • Farm configuration information
  • Published application configurations
  • Server configurations
  • Citrix administrator accounts
  • Printer configurations

The System Requirements lists the databases you can use for the farm data store. For information about supported database versions, see http://support.citrix.com/article/CTX114501.

Choosing a Database

Consider these factors before deciding which database product to use:

  • The number of servers you currently plan to have in the farm, and whether or not you plan to expand that number
  • Whether or not you have a database administrator with the expertise to configure and manage a data store running on SQL Server or Oracle
  • Whether or not you foresee the enterprise expanding, which would result in expanding the size and maintenance of the database
  • Any database maintenance requirements, such as backup, redundancy, and replication

General recommendations are listed below, based on the following size table.

Small Medium Large Enterprise
Servers 1-50 25-100 50-100 100 or more
Named Users < 150 < 3000 < 5000 > 3000
Applications < 100 < 100 < 500 < 2000
  • Microsoft SQL Server and Oracle are suitable for any size environment and are recommended for all large and enterprise environments. When deploying large farms across a WAN, you can obtain a performance advantage by replicating the data store and distributing the load over multiple database servers. SQL Server and Oracle are suitable for large farms and support replication.

    Do not install XenApp on the SQL Server or Oracle database server.

  • SQL Server Express is suitable for all small and many medium environments located in one physical location, which do not have branch offices across a WAN.

See the database product documentation for hardware requirements for the database server.

Important: Ensure that the data store is backed up regularly. If the data store database is lost, you must recreate the farm. You cannot recreate the data store from an existing farm.

Database Server Hardware Performance Considerations

Increasing the CPU power and speed of the database server can improve the response time of queries made to the data store when:

  • Starting the Citrix IMA Service on multiple servers simultaneously
  • Adding a server to the farm
  • Removing a server from the farm

The response time of other events (such as starting the IMA Service on a single server, recreating the local host cache, or replicating printer drivers to all servers in the farm) is affected more by the farm size than by the data store response time.

Adding processors to the server hosting the data store can improve response time when executing multiple simultaneous queries. In environments with large numbers of servers coming online simultaneously and at frequent intervals, additional processors can service requests faster.

The capabilities of the processor on the database server affect management console performance, how long it takes to add (configure) and remove a server from the farm, and how long it takes to start multiple servers simultaneously.

In the following chart, five sample farm configurations (A through E) are listed, with measurements of various metrics in the farm.

Configuration A B C D E
Number of servers in farm 50 100 250 500 1000
Number of applications published to all servers 50 50 50 50 50
Number of user policies 25 25 25 25 25
Printers per server 5 5 5 5 5
Printer drivers installed per server 25 25 25 25 25
Network print servers with printers 5 5 5 5 5
Number of Load Manager load evaluators 10 10 10 10 10
Number of application folders in management console 10 10 10 10 10
Number of server folders in management console 8 16 25 50 50
Number of Application Isolation Environments 10 10 10 10 10
Number of Citrix administrators 10 10 10 10 10
Size of data store database in megabytes 32 51 76 125 211

The following table lists suggested hardware for the server hosting the data store, for each configuration in the previous table.

Configuration A B C D E
Dual Pentium 4/1.6GHz with 2GB RAM X X X
Dual Pentium 4/3.0GHz with 4GB RAM X X X X
Quad Pentium 4/3.0GHz with 4GB RAM X X X X X

The actual performance of a farm’s data store varies depending on the database engine and the level of performance tuning achieved.

Replication Considerations

When you join a new server to a XenApp farm, a significant amount of time can be spent waiting for the server’s Citrix Independent Management Architecture (IMA) service to start and come online. As a result, you might choose to configure SQL data store replication at each remote site, to allow member servers to point to their local SQL subscriber and avoid the slowness of traversing the WAN. However, as your farm expands geographically, the overhead of administering SQL subscribers at each of your sites becomes a burden.

In XenApp 6.5, you can configure servers in session-host mode (also known as session-only mode). This server mode allows XenApp servers to join a farm in significantly less time with substantial bandwidth savings.

When a XenApp server joins a farm, it performs numerous read and write operations to the IMA data store as well as a download of the farm data to its Local Host Cache (LHC). In previous releases of XenApp, all member servers of the farm were required to download all farm data to their LHC during a join, resulting in a large amount of data store transactions and bandwidth consumption. In XenApp 6.5, you can dedicate a select few servers as XenApp controllers which are responsible for farm management tasks, while the remaining member servers are session-only servers whose sole task is to host user sessions. XenApp controllers must synchronize all of the farm data, while session-only servers must synchronize only a subset of the information to their LHC. These changes result in fewer database transactions, less bandwidth consumption, and faster IMA startup performance.

While session-only XenApp servers can host XenApp user sessions, they cannot perform the role of data collectors, nor can they participate in or trigger a data collector zone election. The XML service does not run on session-only XenApp servers; therefore, the Web Interface cannot use them to perform application enumerations. Additionally, management tasks such as AppCenter discovery or PowerShell tasks cannot be run directly on a session-only server. However, with proper planning and placement of XenApp controller servers, leveraging the session-only model can optimize your farm performance and reduce IMA bandwidth and server provisioning time.

You specify the XenApp server mode through the Server Role Manager when you configure the XenApp role to join a farm. For more information, see the XenApp Server Mode section in Before Configuring XenApp.

If you used data store replication in previous XenApp deployments, note that in XenApp 6.5:

  • Replication is no longer required because IMA architectural changes have significantly improved WAN performance.
  • Future versions of Microsoft SQL Server may not support the replication model that XenApp supports (transactional replication with immediate updating subscribers).

Therefore, although you can replicate a XenApp 6.5 data store on SQL Server 2008 R2 and earlier versions, you do not need to, and you may not be able to with later SQL Server versions.

Planning for Configuration Logging and IMA Encryption

The IMA encryption feature provides a robust AES encryption algorithm to protect sensitive data in the IMA data store. Enabling IMA encryption provides an additional layer of security for the data preserved by the Configuration Logging feature.

If you do not enable IMA encryption, XenApp uses the standard encryption used in previous versions of XenApp. The Securing Server Farms documentation contains more information about IMA encryption, Configuration Logging, and when to enable these features.

To enable IMA encryption, you specify a key which is used for all the servers in your farm. To generate the key, use CTXKEYTOOL, which is available on the installation media.

For custom installations or provisioning servers in large environments, consider:

  • Deploying XenApp by using images, and including the key file as part of the server image
  • Generating a key, putting the key in a folder on your network, using a UNC path to specify the location, and performing an unattended installation

If you have multiple farms in your environment, Citrix recommends you generate separate keys for each farm.

Citrix best practices reference list for XenApp/XenDesktop design

Posted on by

source: http://www.bjornbats.nl/?p=580

design part best practice guide
active directory Edoc-Recommendations for Active Directory Environments
application virtualization virtual application management with microsoft application virtualization 4.5/4.6 and system center configuration manager 2007R2 2012
search for app-v and configmgr whitepaper
bandwidth ctx124457 performance assessment and bandwidth analysis for delivering xendesktop to branch offices
datastore edoc datastore reference
datastore CTX112524-Citrix Presentation Server and Microsoft SQL 2005 Configuration
datastore CTX118849-Installing SQL 2008 on Windows Server 2008. Datastore
Replication with XenApp 5.0 using SQL 2008 with Windows Authentication
datastore Edoc-planning a citrix high available citrix datastore
datastore ctx127939-XenDesktop 5 Database Sizing and Mirroring Best Practices
farm&zone CTX129106-Scaling Big – DaaS and SaaS Deployments for Citrix Service Providers
Scaling to 1,000 servers in a single farm
farm&zone edoc-planning zones in a wan
HA & scalability & sizing Citrix-blogpost-estimating xenapp 6.5 hosted shared desktop scalability
HA & scalability & sizing CTX 131102 Citrix XenApp 6 5 – Enterprise Scalable XenApp Deployments
HA & scalability & sizing CTX123684-Delivering 5000 Desktops with XenDesktop 4
HA & scalability & sizing CTX134979 -High Availability for XD and XA – Planning Guide
HA & scalability & sizing fujitsu-terminal_server_sizing_guide_en
license Remote Desktop License Server Discovery
license CTX114847-LICENSE SERVER SIZING AND SCALABILITY
license edoc- setting up a citrix license server on a microsoft cluster
netscaler edoc-netscaler high availability 
network Citrix-Blogpost-Quality of services
optimization CTX131577-XA – Windows 2008 R2 Optimization Guide.pdf
optimization CTX125060 Best_Practices_for_Optimizing_HDX_Technologies_for_XenDesktop_4
overall CTX124481 Advanced Farm Administration with XenApp Worker Groups
overall CTX119686-Top_10_Items_Found_by_Citrix_Consulting_on_Assessments_v2
overall CTX132799-XenDesktop and XenApp – Best Practices
overall edocs designing a xenapp 6 farm
patchmanagement CTX120842-Best Practices for Citrix XenApp Hotfix Rollup Pack &Installation and Deployment
ports CTX101810-CitrixPorts_by_Product_and_Port_2060
printing Edoc-Overview of Client and Network Printing Pathways
printing edoc-improve printing performance
printing CTX18234-printing architecture solution
printing CTX131337-TechEdge Barcelona 2011 – Integrating your branch office successfully with optimized printing solutions
profiles CTX110351 User Profile Best Practices for MetaFrame Presentation Server
profiles Profile Management Frequently Asked Questions
profiles CTX119036-User-Profile-Manager-Best-Practices-Guide-Final
pvs CTX120464-PVS_for_XenApp_Best_Practices
pvs CTX134945-Provisioning Services Networking Planning Guide
pvs CTX124791-Citrix Provisioning Services 5.6 SP1 Installation and Configuration Guide
pvs CTX124792-Citrix Provisioning Services 5.6 SP1 Administrator’s Guide
pvs CTX127438-Provisioning Services Components Interaction
pvs CTX127549-Provisioning Services 5.6 Best Practices
pvs CTX120803-Citrix Provisioning Services Security Backgrounder
running xenapp virtual CTX129761 XenApp Planning Guide – Virtualization Best Practices
running xenapp virtual vmware-citrix-xenapp-best-practices-EN
storage CTX130632-XD – Planning Guide – Storage Best Practices
thin clients citrix blogpost-selecting thin clients for xendesktop 4
thin clients citrix blogpost-HDX Ready thin client test kit
thin clients hdx citrix blogpost-hdx and thin clients
in the hld 1883 only the mandatory requirement that the thin client must be hdx ready is mentioned.http://www.citrix.com/English/partners/programs/fourthLevel.asp?programID=1681660&tlID=163199&flID=1859519What about the management of the thin clients and reuse of existing tooling like sccm

http://henkhoogendoorn.blogspot.nl/2012/09/thin-client-management-in-configmgr-2012.html?spref=tw
training Citrix recommends the following levels of training as best practice:
· Level 1 (Help Desk): Citrix Certified Administrator (CCA) on XenApp and XenDesktop
· Level 2 (Production Support Engineer): Citrix Certified Advanced Administrator (CCAA)
· Level 3 (Build Engineer): Citrix Certified Enterprise Engineer (CCEE)
· Level 4 (Architect): Citrix Certified Integration Architect (CCIA) and more
XenDesktop and XenApp – Best Practices guide
uac edoc-user account control
xendesktop citrix blogpost-xendesktop design handbook
xendesktop CTX127842-how to configure the logoff behavior of a desktop group in xendesktop 5
administration Best Practices for XenApp Administrators 
virusscan Citrix Guidelines for Antivirus Software Configuration 
printing xendesktop and xenapp printing planning guide