VMware vCenter XVP Manager and Converter

    VMware vCenter XVP Manager and Converter provides basic virtualization management capabilities for non-vSphere hypervisor platforms towards enabling centralized visibility and control across heterogeneous virtual infrastructures. It also simplifies and enables easy migrations of virtual machines from non-vSphere virtualization platforms to VMware vSphere.

    Features

    • Management of the following Microsoft Hyper-V platforms:
      • Microsoft Hyper-V Server 2008
      • Microsoft Windows Server 2008 (64-bit) with Hyper-V role enabled
      • Microsoft Hyper-V Server 2008 R2
      • Microsoft Windows Server 2008 R2 with Hyper-V role enabled
    • Familiar vCenter Server graphical user interface for navigating through and managing non-vSphere inventory
    • Ease of virtual machine migrations from non-vSphere hosts to vSphere inventory
    • Compatible with VMware vCenter Server 4.0 & 4.1
    • Scalable up to management of 50 non-vSphere hosts

For more detailed information refer to the vCenter XVP Manager and Converter Technology Preview Release Notes and Installation Guide (included in zip file download).

VIDEO’s

Installation

Host Operations

Convert HyperV VMs to vSphere

Guest VM Operations inside HyperV

Download: HERE

VMware View 4.6 New Features

VMware released VMWare View 4.6

Updated Features:
Security servers can now accommodate PCoIP connections – Security servers now include a PCoIP Secure Gateway component. The PCoIP Secure Gateway connection offers the following advantages:

  • The only remote desktop traffic that can enter the corporate data center is traffic on behalf of a strongly authenticated user.
  • Users can access only the desktop resources that they are authorized to access.
  • No VPN is required, as long as PCoIP is not blocked by any networking component.
  • Security servers with PCoIP support run on Windows Server 2008 R2 and take full advantage of the 64-bit architecture.

Enhanced USB device compatibility – View 4.6 supports USB redirection for syncing and managing iPhones and iPads with View desktops. This release also includes improvements for using USB scanners, and adds to the list of USB printers that you can use with thin clients. For more information, see the list of View Client resolved issues.

Keyboard mapping improvements – Many keyboard-related issues have been fixed. For more information, see the list of View Client resolved issues.

New timeout setting for SSO users – With the single-sign-on (SSO) feature, after users authenticate to View Connection Server, they are automatically logged in to their View desktop operating systems. This new timeout setting allows administrators to limit the number of minutes that the SSO feature is valid for.
For example, if an administrator sets the time limit to 10 minutes, then 10 minutes after the user authenticates to View Connection Server, the automatic login ability expires. If the user then walks away from the desktop and it becomes inactive, when the user returns, the user is prompted for login credentials. For more information, see the VMware View Administration documentation.

VMware View 4.6 includes more than 160 bug fixes – For descriptions of selected resolved issues, see Resolved Issues.

Support for Microsoft Windows 7 SP1 operating systems (Not Experimental of RC wrong on the VMware site)

VDI Documentation
VMware View 4.6 Release Notes
VMware View Architecture Planning
VMware View Administration
VMware View Installation
VMware View Upgrades
VMware View Integration
View4_Marketecture_05

NTFS Chkdsk Best Practices and Performance

Claus Joergensen, one of the founding fathers of Windows Storage Server, had a great post today about a new white paper, available here, discussing the best practices and guidance for sizing NTFS volumes. The paper also has details on self-healing NTFS and Chkdsk execution times on Windows Server 2008 R2.

When planning Windows file server deployments, we are often asked questions such as “How large can I make my volumes?” or “How long will it take to repair a volume?”. This white paper helps answer these questions.

Table of Contents:

  • Self-Healing and Chkdsk
  • How to run Chkdsk
  • Chkdsk Exit Codes
  • Improving General Availability of the Server
  • Chkdsk performance on Windows Server 2008 R2
  • Block Caching Improvements in Windows Server 2008 R2
  • Effect of Volume Size on execution time of Chkdsk
  • Effect of Number of files and Different OS versions on execution time of Chkdsk
  • Effect of Physical Memory at different Number of files on execution time
  • Effect of short file names on Chkdsk execution time
  • Effect of Enabling/Disabling short file names
  • Conclusion
  • Call to Action
  • Resources   

If you are planning a Windows file server deployment or is looking to upgrade an existing Windows file server deployment to Windows Server 2008 R2, you should consult the white paper. It outlines how with Windows Server 2008 R2, NTFS can scale to easily support 15 TB file systems with 10 million files! Even with hundreds of millions of files the Chkdsk execution times are really fast. My favorite statistic is that a volume with 300 million files is able to Chkdsk in about 6 hours, that is so much faster than the old days.

SOURCE: http://blogs.technet.com/b/storageserver/archive/2011/02/23/guidance-for-sizing-ntfs-volumes.aspx

Exchange 2010 Opening multiple shared calendars & additional mailboxes

Current Status: Issue with mitigation

Exchange 2010 SP1 together with the resolutions mentioned later in this section, allows you to open as many as 16 shared calendars or additional mailboxes simultaneously independent on whether the mailboxes are located on Exchange 2003, 2007, or 2010. If you have more than 16 calendars or additional mailboxes opened, you may randomly see error message similar to the one shown in Figure 4.


Figure 4:
Error message when opening more than 16 calendars

With Exchange Server 2010 RTM deployed into an Exchange 2003 or Exchange 2007 organization, it was a common issue that when an Exchange 2003 or Exchange 2007 user tried to open more than two additional Exchange 2010 mailboxes or shared calendars using Outlook 2003, she would receive one of the following error messages:

  • The set of folders could not be opened
  • The information store could not be opened
  • Unable to display the folder. The information store could not be opened

When an Exchange 2007 user tried to send an e-mail using Outlook 2003, she would sometimes also receive the following error message:

  • Task ‘Microsoft Exchange Server – Sending’ reported error (0x800C8100): ‘Unknown Error 0x800c8100’

These issues were resolved with Update Rollup 2 for Exchange 2007 Service Pack 2 and a hotfix that were released for Exchange 2003 SP2. More information about the issues and how they are resolved can be found in the following KB articles:

    Although the above mentioned issues were resolved, some customers, partners, and individuals in the Exchange communities reported they still experienced issues when trying to open approximately multiple shared calendars and/or additional mailboxes using Outlook 2003.

    For most organizations, the issue can be remediated by installing Exchange 2010 SP1 as this service pack includes a fix that makes it possible for an Exchange 2003, 2007, or 2010 user to open as many as approximately 16 shared calendars or additional mailboxes using Outlook 2003.


    Figure 5:
    By default approximately 16 Calendars can be opened using Outlook 2003

    If you have users that needs to open more than 16 shared calendars or additional mailboxes using Outlook 2003, you can adjust the RPC related throttling policy settings using the Set-ThrottlingPolicy cmdlet. Specifically, you need to increase the value for “RCAMaxConcurrency” which by default is set to “20”. The RCAMaxConcurrency parameter indicates how many concurrent connections an RPC Client Access user can have against a server running Exchange 2010 at one time.


    Figure 6:
    Default setting for the RCAMaxConcurrency throttling policy value

    For instance, to increase the value of the “RCAMaxConcurrency” setting in the default throttling policy from 20 to 2147483647, open the Exchange Management Shell and run the following command to first create a variable for the policy:

    $a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

    Then pipe the variable to the Set-ThrottlingPolicy commandlet:

    $a | Set-ThrottlingPolicy -RCAMaxConcurrency 2147483647


    Figure 7:
    Increasing the value for the RCAMaxConcurrency throttling policy setting

    In order to apply the changes, restart the “Microsoft Exchange Throttling” service on each CAS server in the organization.

    You can read more about Exchange 2010 SP1 throttling policies in the Exchange 2010 documentation on Microsoft TechNet.

    If you still have issues opening shared calendars or additional mailboxes, you may want to increase the value of the RCAMaxConcurrency throttling policy setting to 100 or even higher. Read more in Error message when Outlook 2003 clients try to open multiple shared calendars in Exchange Server 2010: "The connection to the Microsoft Exchange server in unavailable. Outlook must be online or connected to complete this action".

    If you see event 4696 with a description similar to the following logged in the application log on the Mailbox servers in the organization:

    "Mapi session "00cc8dde-64d7-4353-8050-00fc2057aae3: /O=xxxx/OU=xxxx/cn=Recipients/cn=ward" exceeded the maximum of 32 objects of type "session"."

    You need to increase the maximum allowed sessions per user and/or maximum allowed service sessions per user limit from "32" to "64" or even higher. See more information at: Exchange 2010 SP1 Store Limits.

    but when I tried to add the “szMaxAllowedSessionsPerUser and/or “szMaxAllowedServiceSessionsPerUser”, I still saw 9646 in the app log.

    Guess why? yes the registry keys are actually listed with wrong names in that article. Instead of:

    • szMaxAllowedSessionsPerUser
    • szMaxAllowedServiceSessionsPerUser

    You need to use:

    • Maximum Allowed Sessions Per User
    • Maximum Allowed Service Sessions Per User

    And then everything worked as expected…

    Hopefully the TechNet page is updated soon.

    Special Thanks to Henrik Walther

    Deploy office 2010 and a previous office version together on one PC with MDT 2010

    Deploy office 2010 and  a previous office version together on one PC with MDT 2010. Then you need to do the following things

    Needed.
    – Office 2010 ISO
    Office 2010 Administrative Template files (ADM, ADMX/ADML) and Office Customization Tool

    1. Make sure you have a working Office 2007 deployment. Check this How to deploy Office 2007 with MDT

    2. Extract the Office 2010 ISO to the application folder on de MDT Server

    2. Extract AdminTemplates_32.exe or AdminTemplates_64.exe to a folder.

    3. Copy the Admin folder that you can find in the extracted folder to the Office 2010 folder that you created at step 1.

    4. Run setup.exe /admin

    5. Check the Screenshots for the settings
    imageimage
    imageimage

    6. Save the file in Updates folder that you find in Office folder. I named the file setup.MSP

    7. Create a new application without source files.

    imageimage
    imageimage
    image

    Command Line is:
    setup.exe /adminfile “\\mdtservername\deploymentshare$\Applications\Microsoft Office 2010 x86\Updates\setup.msp

    Service Pack 1 for Windows Server 2008 R2 en Exchange

    The following versions of Exchange are supported to run on Windows 2008 R2 SP1 (the RTM version of SP1):

    • Exchange 2010 SP1
    • Exchange 2010 RTM
    • Exchange 2007 SP3

    Please note that Exchange 2007 was not supported to run on Windows 2008 R2 at all before Exchange 2007 SP3 release.

    Windows 2008 R2 SP1 includes the hotfixes required to install Exchange 2010 SP1 (listed in Exchange 2010 SP1 FAQ and Known Issues — 979744, 983440, 979099, 982867 and 977020). If you’re installing Exchange 2010 SP1 on a server running Windows 2008 R2 SP1, you don’t need to install these hotfixes separately Smile

    Exchange 2010 RPC Encryption Requirement

    Current Status: Non-issue

    Exchange 2010 SP1
    With Exchange 2010 RTM, the RPC encryption requirement was an issue with mitigation. However, in Exchange Server 2010 Service Pack 1, the RPC encryption requirement has been disabled by default. This means that any new Exchange 2010 SP1 Client Access Servers (CAS) deployed in the organization won’t require encryption and Outlook 2003 clients will connect without the need to enable the RPC encryption feature in the Outlook profile.

    Important
    Having the RPC encryption requirement on an Exchange 2010 CAS server disabled doesn’t lower the security between Outlook 2007/2010 and any Exchange 2010 CAS server. RPC communication for these Outlook versions will remain encrypted as long as the client has the RPC encryption feature enabled. It’s only the requirement itself that is disabled on the Exchange 2010 CAS server.

    Exchange 2010 CAS servers deployed prior to Service Pack 1, or upgraded to Service Pack 1, will retain the existing RPC encryption requirement setting.

    Exchange 2010 RTM
    When upgrading or migrating an organization that fully or partly uses Outlook 2003 to Exchange 2010, we hear there are out of the box problems, when trying to connect an Outlook 2003 client to an Exchange 2010 RTM mailbox? We heard this is because an Exchange 2010 RTM Client Access Server by default requires an Outlook client to support RPC encrypted traffic in order to be able to connect.

    While it’s true the default configuration of an Outlook 2003 client doesn’t have support for RPC encryption, this requirement is fully supported with Outlook 2003.

    There are two methods that can be used in order to have Outlook 2003 clients connect to an Exchange 2010 RTM mailbox:

    Method 1: Enable the RPC encryption support in Outlook 2003

    If “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” is enabled under the “Security” tab in the Outlook 2003 profile (see figure 1), the client will be able to connect to an Exchange 2010 RTM mailbox.


    Figure 1:
    RPC Encryption enabled in Outlook 2003

    If you are working with or for a small organization, it may be acceptable the end user enables this feature manually, but if you have thousands of users in the organization, you would want to enable it using a group policy (GPO). The steps necessary to implement a GPO to enable this setting are included in this KB article.


    Important

    The “EnableRPCEncryption” registry key mentioned in the KB article was originally introduced via a hotfix for Outlook 2003 SP2. This means that clients that either runs Outlook 2003 SP2 or an older version of Outlook 2003 doesn’t respect this registry key. In addition, Outlook 2003 clients not running SP3 are not supported by Microsoft.

    Method 2: Disable the RPC Encryption requirement on the Client Access Servers

    Instead of enabling support for RPC encryption in the Outlook 2003 profiles, you also have the option of disabling the requirement for RPC encryption on all Exchange 2010 RTM Client Access Servers in the organization.

    This can be accomplished using the Set-RpcClientAccess cmdlet:

    Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False


    Figure 2:
    RPC Encryption requirement disabled on Exchange 2010 CAS servers

    As mentioned earlier Exchange 2010 SP1 servers that hasn’t been upgraded from Exchange 2010 RTM has the RPC encryption requirement disabled by default.

    The following KB article describes the symptoms and remediation in detail:

    The core Exchange 2010 TechNet documentation also describes the configuration that can be used to remediate the issue:

    Important
    Unmanaged client machines cannot be controlled using GPOs or login scripts. If you have unmanaged machines connecting to Exchange 2010 using Outlook 2003, one solution would be to send those users a script or a registry file which they can run manually on their machine to enable the RPC encryption setting.

    Special Thanks to Henrik Walther

    Exchange 2010 Exchange Server name appears as Instance – <GUID>

    Current Status: Issue – no issue

    A few customers, partners, and individual folks in the Exchange community have reported that a few of the Exchange 2010 users running Outlook 2003 randomly have issues connecting to their mailbox. After examining the mail profile in Outlook 2003, you can see the Exchange server name appears as Instance-<GUID> where <GUID> is a randomly generated GUID (or number). Re-resolving (‘Check Name’) the appropriate server name in the Outlook mail profile resolves the issue.


    Figure 11: Instance-GUID issue in Outlook 2003

    Note
    Seeing Instance-<GUID> in conversation between an Outlook 2003 client and an Exchange 2010 server is normal (when Instance-<GUID> appears inside Outlook in the folders list view on left hand side); It does NOT mean you are hitting this particular issue. You experience this issue if the Outlook mail profile gets updated to refer to the Exchange server as Instance-GUID.

    The problem behavior can be triggered by networking issues, patch applications, server reboots, etc. It requires Outlook 2003 to lose connectivity to Exchange and have a delegate mailbox logon attempted on a connection before the primary mailbox logon is attempted on that connection. This can affect users who are accessing shared mailboxes or folders of other users from their Outlook 2003 while connecting to Exchange 2010.

    Currently there is no proper resolution available for this issue. However, to remediate this issue temporarily, simply re-resolve the Exchange server name in the Outlook mail profile. If possible, you may also remove the shared mailboxes or shared folders (like calendars) from the profile, preventing this issue from occurring in the future or create a new mail profile in Outlook.

    Microsoft is working to investigate this issue for a fix. You can contact Microsoft Support to report this issue and request further assistance. Currently no KB article exists for this issue.

    Update:

    Microsoft has confirmed this to be a bug and the bug was assigned to the Outlook team within Microsoft. It has been fixed and a hotfix can be downloaded here: http://support.microsoft.com/kb/2510153

     

    Special Thanks to Henrik Walther & Jaap Wesselius