DCSIMG
Yuval Sinay
Sign in | Join | Help

Yuval Sinay

Yuval's blog.

Exchange 2010 Database Availability Groups (DAGs) and Witness Server location - Design Considerations

Published at May 19 2012, 09:28 PM by yuval14

Exchange 2010 Database Availability Groups (DAGs) is an excellent solutions for customers that require to provide a high availability solution for the Exchange system.  However, some customers skip important design steps during Exchange 2010 Database Availability Groups (DAGs) deployment.

The first common issue, is the Witness Server location. In most of the cases, the Witness Server should be reside near the Mailbox server that provide service to the local users. For example, in case that most of the users reside in New York, the Witness Server should be deployed in New York.

The second common issue, is the amount of Database Availability Groups (DAGs) that should be deployed.  In most of the cases, a dedicated Database Availability Groups (DAG) should be deployed for each location. For example, if you have users in New York and London, then two Database Availability Groups (DAGs) should be deployed.

The next common issue, is misunderstanding of the Alternate Witness Server role. Mr. Clint Boessen  (MVP), wrote an excellent post on Alternate Witness Server role:

“Although you can configure an Alternate Witness Server (and corresponding Alternate Witness Directory) for a DAG at any time, the Alternate Witness Server will not be used by the DAG until part-way through a datacenter switchover; specifically, when the Restore-DatabaseAvailabilityGroup cmdlet is used.”

Source: Alternate Witness Server in Database Availability Groups

Another common issue, is using domain controller as Witness Server. Although you can use domain controller as Witness Server, the side effect that you expose the domain controller to common security risks. Mr. Scott Schnoll (MSFT) wrote an excellent post on this issue: Witness Server Warning Message When Using Certain Database Availability Group Tasks

Also, some customers didn’t enabled Datacenter Activation Coordination (DAC) while using Database Availability Groups (DAGs). According official Microsoft documentation:

“Datacenter Activation Coordination (DAC) mode is a property setting for a database availability group (DAG). DAC mode is disabled by default and should be enabled for all DAGs with two or more members that use continuous replication. DAC mode shouldn't be enabled for DAGs in third-party replication mode unless specified by the third-party vendor.”

Source:Understanding Datacenter Activation Coordination Mode

Note: In some scenarios, Datacenter Activation Coordination (DAC) shouldn’t be enabled. Please review Microsoft official documentation for further information.

As summary for this topic, I add the following Visio diagram:

DAG

For further information,please review: Understanding Database Availability Groups

תגים:, , ,

Cumulative Update 6 for System Center Operations Manager 2007 R2 (KB2626076)

Published at May 15 2012, 08:22 AM by yuval14

"Cumulative Update 6 contains a number of fixes for Operations Manager 2007 R2 including cross platform components, support for IBM AIX 7.1 (POWER), support for Oracle Solaris 11 (x86 and SPARC), as well as all of the fixes from Operations Manager 2007 R2 CU5." The new update can be download from the following link.

תגים:, ,

Best Practice Installing Exchange 2010 Service Packs & Rollups

Published at May 07 2012, 12:35 AM by yuval14

A few customers reported on a failure during Exchange 2010 Service Pack 2 Installation. The failure not stop the Exchange upgrade process, but in the end the Exchange server was down and reinstallation / resorting from backup - were the only solutions that help to resolve this issue.

Due this, I add a few recommendations that may help to reduce the risk during Exchange 2010 Service Pack / Rollup deployment:

Note: Most of the Exchange Service Packs / Rollups doesn’t contain a rollback mechanism.

1. Never install the Exchange updates or patches along with other windows updates.

2. Install the Rollups separate and do not club with Service pack upgrades.

3. Stop all the Microsoft and 3rd party services (e.g. Antivirus, Backup etc.) before upgrade.

4. Take a clean copy of the Binary files & Exchange registry keys, because at times the setup may fail after “Removing Files” stage.

5. Before upgrade reboot the server and confirm there is no issues with Exchange (Check app log and System logs for exchange related errors)

6. Run ExBPA and fix the critical errors before upgrade

7. Verify that the account that is using during the installation have the required access permissions:

a. Local Administrator Privilege and full control to the Exchange registry keys (even if the account that you are using have a local Administrator privilege).

b. Membership in the Exchange Organization Management Role.

c. Membership in the Domain Admins Group.

d. If the Service Pack / Rollup require a Schema Upgrade, a member ship in “Schema Admins” group is required.

8. Its highly recommended to test the Service Pack / Rollup in a lab before moving to production deployment.

9. In case that the server is a member in a Database Availability Group (DAG) , first  -move all the databases to alternative host and then temporary disable/block this server from providing services.

10. Its highly recommended to upgrade all the HAB/CAS servers in the organization first and then upgrade all the mailbox roles.

11. Verify that you are using the latest version of third party software for Exchange server (e.g. Backup, Antivirus etc.).

תגים:,

SQL Reporting Services Migration Tool

Published at Apr 22 2012, 03:33 AM by yuval14
  • SQL Reporting Services Migration Tool allow you to migrates reports and other artifacts from one report server to another report server. It can also be used as a backup and restore tool for Reporting Services.
  • “You can use RSMigrationTool or RSMigrationUI to backup your native report server.
  • To restore or migrate the native server, run the Migration.ps1 from a PowerShell console.
  • Source and target server must be SQL Server Reporting Services 2008 R2 or later.
  • Source server
    • Source server must be native mode using Windows authentication. (We are working on support for SharePoint integrated mode and other authentication schemes.)
    • Permissions and roles from source server are not backed up o Configuration in source server is not backed up.
    • Reports and other artifacts in deeply nested subfolders may not be backed up. This is due to Windows OS restriction on the maximum length for the full path of the backup files and folders. (We are working towards a solution.)
    • Linked reports are not support in SharePoint mode, hence not backed up.
    • Database connection to source server catalog is made using Windows Integrated credentials of the user running the tool.
  • Target server
    • Target server must be SharePoint integrated mode. (We are working on support for native mode.)
    • The web application must be using Windows classic authentication mode. (We are working on support for other authentication schemes.)
    • Target server must be correctly configured. Target document library and folder must be created. For SSRS 2012, service application must be created and configured.
    • The owner of Reporting artifacts after migration is set to the user who performed migration. (We are working towards a solution.)
    • Subscription owners are set after they are migrated. If the owner does not have CreateAlerts/ManagedAlerts permission, the operation will fail.
    • Report parts are not linked correctly to the Report. (We are working towards a solution.) o Database connection to target server catalog is made using Windows Integrated credentials of the user running the tool.”
    • The tool can be download from the following link.
תגים:, , ,

How to renew User/Computer certificate without require to do application side changes

Published at Apr 21 2012, 07:58 PM by yuval14

The renewal process of user/computer certificate require (in the most of the cases) to implemented changes in the application side (e.g. IIS,Outlook etc.),

As a workaround for this “limitation”, the renewal process of the User/computer certificate can be set to use exiting certificate key.

However, using exiting certificate key may reduce the system security level, and this may lead to system/certificate compromise.

Warring: To reduce the security risk of implementing changes in the Enterprise PKI (Public Key Infrastructure), its highly recommended to test this changes in a lab - before making changes in the production environment.

To renew the certificate by using exiting certificate key, please use the following instructions:

A. PKI Prerequisites:

1. Depending on the certificate template type/settings, the Certificate Authority security settings should allow the user that renew the certificate to have the following privilege: “Request Certificates”.

image

2. Depending on the certificate template type/settings, the user that renew the certificate may require the following privilege on the relevant Certificate Template: “Enroll” and/or “Autoenroll”.

image

B. The renewal process:

1. Logon to the computer.

2. Navigate to “Start” –> “Run” and type “mmc” and click “OK” to launch the Management Console 

3. Navigate to “File” > “Add/Remove” Snap In… , select “Certificates” and click “Add”.

4. Select “Computer Account” (or “User Account”) and click “Next”. Then", click “Finish”. Once back on the Snap In screen, click “OK”.

5. Expand “Certificates” > “Personal” and click on “Certificates”.

6. Right-click on the required certificate and select “All Tasks” > “Advanced Operations” > “Renew This Certificate with the Same Key”.

7. Click “Next”, and then “Enroll”. Once complete, click “Finish”.

תגים:, ,

System Center 2012 – Configuration Manager Component Add-ons and Extensions

Published at Apr 20 2012, 12:07 AM by yuval14

“Following System Center 2012 – Configuration Manager add-ons and extensions are available for download:
Package Conversion Manager (PCM) The Microsoft System Center 2012 Configuration Manager Package Conversion Manager allows for converting packages and programs into applications and deployment types in System Center Configuration Manager 2012. There is a migration feature which will be released with the Configuration Manager 2012 that allows packages to be migrated from 2007 to 2012. Once you have migrated your package objects and installed PCM then it is just a matter analyzing your packages in order to determine which readiness state each are in, and then converting those packages that are in the appropriate readiness state. . This release comes in 4 languages.
Physical to Virtual (P2V) Migration Toolkit
The System Center 2012 Configuration Manager P2V Migration Toolkit facilitates the re-utilization of existing x64 server hardware using virtualization technologies, Windows Server 2008 R2 and Hyper-V. The P2V Migration Toolkit was specifically designed to assist in situations where there are remote Configuration Manager 2007 SP 2 site servers that need to be retained during side-by-side migration process to System Center 2012 Configuration Manager. The P2V Migration Toolkit is geared to supporting P2V migrations at remote, branch offices that do not have existing onsite Virtual Machine Manager infrastructure.
System Center 2012 Configuration Manager Toolkit The Microsoft System Center 2012 Configuration Manager Toolkit contains nine downloadable tools to help you manage and troubleshoot Microsoft System Center 2012 Configuration Manager. The following list provides specific information about each tool in the toolkit.

  • Client Spy - A tool that helps you troubleshoot issues related to software distribution, inventory, and software metering on System Center 2012 Configuration Manager clients.
  • Policy Spy - A policy viewer that helps you review and troubleshoot the policy system on System Center 2012 Configuration Manager clients.
  • Security Configuration Wizard Template for Microsoft System Center 2012 Configuration Manager - The Security Configuration Wizard (SCW) is an attack-surface reduction tool for the Microsoft Windows Server 2008 R2 operating system. Security Configuration Wizard determines the minimum functionality required for a server's role or roles, and disables functionality that is not required.
  • Send Schedule Tool - A tool used to trigger a schedule on a client or trigger the evaluation of a specified DCM Baseline. You can trigger a schedule either locally or remotely.
  • Power Viewer Tool – A tool to view the status of power management feature on System Center 2012 Configuration Manager clients.
  • Deployment Monitoring Tool - The Deployment Monitoring Tool is a graphical user interface designed help troubleshoot Applications, Updates, and Baseline deployments on System Center 2012 Configuration Manager clients.
  • Run Metering Summarization Tool - The purpose of this tool is to run the metering summarization task to analyze raw metering data
  • Role-based Administration Modeling and Auditing Tool – This tool helps administrators to model and audit RBA configurations.
  • License Tracking PowerShell Cmdlets - The PowerShell cmdlet “Get-ConfigMgrAccessLicense” is used to get license usage information for all the servers and clients within scope of System Center 2012 Configuration Manager. The cmdlet returns a list of licensable features and a list of unique users and devices per unique licensable feature.”

The System Center 2012 – Configuration Manager Component Add-ons and Extensions can be download from the following link.

תגים:, ,
More Posts Next page »