EMC does not start

EMC has error when launching
The attempt to connect to http://exch01.domain.local/powershell using "KERBEROS" authentication failed: connecting to remote server failed with following error message: access is denied

1. Check all services make sure they are all started
2. Check the time and time zone, make sure it synchronized with DC

Lauch EMC, if it still does not work go to the next steps

3. From exchange server open a command prompt and type
WinRM QuickConfig
Answer "y" or yes to all prompts.
Keep running the above command until it returns a positive result.
(WinRM already set up to receive......blah, blah, blah)
4. After that returns a similar message as above, set they are set to start Default
Windows Remote Management (WS-Management)
World Wide Web Publishing Service.

5. Run IIS Manager. Click on the "Default Site" and select restart

Good luck 

Tip: 7 Best Practices for Physical Servers Hosting Hyper-V Roles

http://technet.microsoft.com/en-us/magazine/dd744830.aspx

Before setting up a physical server to host the Hyper-V role, download, read, and understand information included in the white paper “Performance Tuning Guidelines for Windows Server 2008”. Three sections in this white paper that can have a significant impact on the performance of the physical server discuss tuning the server hardware and setting up the networking and storage subsystems. These are especially critical for Hyper-V because the hypervisor itself sits on top of the hardware layer as described earlier and controls all hardware in Windows Server 2008. The operating system itself essentially runs in a virtual machine, better known as the Parent Partition.

Here are seven best practices for physical servers hosting the Hyper-V role.

Avoid Overloading the Server
Determining the number of virtual machines that will be hosted on the Hyper-V server and the workloads they will be handling is critical. The version of the operating system that will be installed on the physical server can help in this regard, so the first “best practice” is to consider using Windows Server 2008 Datacenter x64 with Hyper-V. The Datacenter x64 edition supports up to 64 processors, 2 terabytes of physical memory, and 16 failover cluster nodes for Quick Migration scenarios and allows unlimited virtual machines to be run in Hyper-V. Selecting a Server Core installation provides added benefits, including enhanced security and lower maintenance.

Ensure High-Speed Access to Storage
For storage, consider using a storage area network (SAN) that is configured with highspeed (10,000 rpms or greater) drives (SATA or SAS) that support queued I/O and Raid 0 +1 configurations. You can use either Fibre Channel or iSCSI SAN hardware.

Install Multiple Network Interface Cards
For networking, be sure to have more than one network card installed on the physical server and dedicate one network interface to Hyper-V server administration. This means no virtual networks in Hyper-V will be configured to use this NIC. For high-workload virtual machines, you might want to dedicate a physical network adapter on the server to the virtual network the virtual machine is using. Ensure virtual machines that share a physical adapter do not oversubscribe to the physical network. Use the Reliability And Performance Monitor to establish a performance baseline for the load and then adjust NIC configurations and loads accordingly.

If you have only a single NIC in the machine that you are configuring the Hyper-V role on and you are doing the configuration remotely (say, in an RDP session) if you choose to bind the Virtual Switch Protocol to the single NIC in the machine, you will be disconnected from your session and a reconnection might not be possible until the newly created virtual network adapter has been properly configured.

Avoid Mixing Virtual Machines That Can Use Integration Services with Those That Cannot
Do not mix on the same physical server virtual machines that can take advantage of Hyper-V Integration Services with those that cannot. Virtual machines that cannot use Integration Services must use legacy network adapters to gain access to the physical network. To accommodate legacy network adapters, you might need to disable some high-end features on the network interface, which can unnecessarily limit the functionality of the synthetic devices. Additionally, using emulated devices places an extra workload on the Hyper-V server.

Configure Antivirus Software to Bypass Hyper-V Processes and Directories
If you are running antivirus software on the physical server, you might want to consider excluding the Vmms.exe and Vmswp.exe processes. Also, exclude the directories that contain the virtual machine configuration files and virtual hard disks from active scanning. An added benefit of using pass-through disks in your virtual machines is that you can use the antivirus software running on the physical server to protect that virtual machine.

Avoid Storing System Files on Drives Used for Hyper-V Storage
Do not store any system files (Pagefile.sys) on drives dedicated to storing virtual machine data.

Monitor Performance to Optimize and Manage Server Loading
When running multiple high-workload virtual machines on a Hyper-V server, ensure a proper aggregate performance baseline is obtained over a specified period of time (say, five days during normal working hours) to ensure the hardware configuration for the physical server is optimal to support the load being placed on it by the virtual machines. If adding more memory, processors, or higher performing storage is not possible, you might need to migrate the virtual machines to other Hyper-V servers.

Raid 10 on x3650M4 with ServerRaid M5510e

It will be easier if raid setup can be done in ServerGuide but unfortunately at the time I was writing this post ServerGuide 9.23 did not work with my x3650 M4 7915.

1. Turn on the server and press F1 at the IBM startup screen.

2. Select Server Settings - Adapter and UEFI drivers then press Enter (to compile the list of drivers)

3. Select the type of Raid card which is in your server

4. You will have 2 options EFI WebBios and EFI CLI . Select option 1 EFI WebBios

5. Select your raid card and click Start

6. Select Configuration Wizard at MegaRaid Bios Config Utility screen.

7. Select New Configuration then Manual Congiguration and click Next

8. Select DriveGroup0 on the right pane (DriveGroups) and select half of physical disk on the left pane (Drives) and click Add to Array.

9. Click Accept DG. MegaRaid will display another drive group DriveGroup1

10. Select new DriveGroup1 on the right pane then select the rest hard disk on the left pane and click on Add to Array.

11. Click Accept DG. In the right pane you will have 3 drivegroups but only 2 has size displayed. The size of dirvegroup is the size of your hard disk.

12. Click Next.

13. In the Span Definition screen select each of DriveGroup in the combo box and click Add to Span.

14. Click Next.

15. If the type of Raid is 10 that means you do thing right. Click Update Size and then Accept.

16. The next screen will display Raid level of every drivegroup. In my case it is Raid0.

17. Click Next then Accept to finish

Good luck :-)

ServeRaid M5110e on x3650M4

Unfortunately at the time I am installing Windows 2008 R2 on x3650M4 (7915) IBM has  not yet updated ServeRaid M5110e on its ServerGuide 9.23. Whatever raid level I selected by following steps in ServerGuide the critical error of raid update failure displayed. It takes me a day before  realizing that I need to find a way round.
First of all the raid setting have to be done via WebRaid because ServerGuide raid setup did not work.
Secondly find out RaidServe M5110e windows driver at http://download2.boulder.ibm.com/sar/CMA/XSA/ibm_dd_sraidmr_5.2.127_windows_32-64.exe and copy it in to USB key
Lastly restart 3650M4 by Windows 2008 R2 DVD and setup as normally except had to upload ServeRaid driver from the USB key before able to see the hard disk partition.
...Go for a beer now

Understanding where your virtual machine files are [Hyper-V]

http://blogs.msdn.com/b/virtual_pc_guy/archive/2010/03/10/understanding-where-your-virtual-machine-files-are-hyper-v.aspx

To be honest, I am surprised that I have not blogged about this before, but today I would like to talk about how virtual machine files are placed on the hard disk. 
Virtual Machine files
The first thing to know is what files are used to create a virtual machine:

• .XML files
• These files contain the virtual machine configuration details.  There is one of these for each virtual machine and each snapshot of a virtual machine.  They are always named with the GUID used to internally identify the virtual machine or snapshot in question.
• .BIN files
• This file contains the memory of a virtual machine or snapshot that is in a saved state.
• .VSV files
• This file contains the saved state from the devices associated with the virtual machine.
• .VHD files
• These are the virtual hard disk files for the virtual machine
• .AVHD files
• These are the differencing disk files used for virtual machine snapshots

Understanding data roots
Hyper-V has a concept of the “virtual machine data root” and the “virtual machine snapshot root”.  These are the locations where the virtual machine configuration (.XML) and saved state (.BIN & .VSV) files are stored.  For example – a virtual machine which had a virtual machine data root of “D:\Foo” and a snapshot data root of “D:\Foo” and had two snapshots would have a file structure like this:
D:\Foo
D:\Foo\Snapshots
D:\Foo\Snapshots\[Snapshot #1 GUID directory]
D:\Foo\Snapshots\[Snapshot #1 GUID].XML
D:\Foo\Snapshots\[Snapshot #2 GUID directory]
D:\Foo\Snapshots\[Snapshot #2 GUID].XML
D:\Foo\Virtual Machines
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]
D:\Foo\Virtual Machines\[Virtual Machine GUID].XML
If the snapshots and the virtual machine had saved states associated with them – then the file structure would look like this:
D:\Foo
D:\Foo\Snapshots
D:\Foo\Snapshots\[Snapshot #1 GUID directory]
D:\Foo\Snapshots\[Snapshot #1 GUID directory]\[Snapshot #1 GUID].BIN
D:\Foo\Snapshots\[Snapshot #1 GUID directory]\[Snapshot #1 GUID].VSV
D:\Foo\Snapshots\[Snapshot #1 GUID].XML
D:\Foo\Snapshots\[Snapshot #2 GUID directory]
D:\Foo\Snapshots\[Snapshot #2 GUID directory]\[Snapshot #1 GUID].BIN
D:\Foo\Snapshots\[Snapshot #2 GUID directory]\[Snapshot #1 GUID].VSV
D:\Foo\Snapshots\[Snapshot #2 GUID].XML
D:\Foo\Virtual Machines
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]\[Virtual Machine GUID].BIN
D:\Foo\Virtual Machines\[Virtual Machine GUID directory]\[Virtual Machine GUID].VSV
D:\Foo\Virtual Machines\[Virtual Machine GUID].XML
Some key things to highlight about data roots:

• We always create a “Virtual Machines” folder under the virtual machine data root and store the virtual machine configuration files there.
• We always create a “Snapshots” folder under the snapshot data rot and store the snapshot configuration files there.
• We fully support multiple virtual machines having the same virtual machine and snapshot data root

Understanding VHD and AVHD locations
.VHD files can be created pretty much anywhere you want.  In Windows Server 2008 R2, .AVHD files are always created in the same location as their parent .VHD files.
Common Virtual Machine File Configuration #1 – Default Virtual Machine Data Root
A virtual machine with a default virtual machine data root is one where you created the virtual machine and accepted the default options in the new virtual machine wizard, specifically where you did not check to “Store the virtual machine in a different location” on the first page of the new virtual machine wizard:

In this configuration option the virtual machine data root and snapshot data root will be set to the path specified under the Hyper-V Settings in the “Virtual Machines” setting, and the virtual hard disk will be created under the path specified under the Hyper-V Settings in the “Virtual Hard Disks” setting:

These paths are normally set to “C:\ProgramData\Microsoft\Windows\Hyper-V” for the “Virtual Machines” setting and “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks” for the “Virtual Hard Disks” setting.  That said – I usually change these settings to “D:\Hyper-V\Configuration Files” and “D:\Hyper-V\Virtual Hard Disks” on my systems as I find this easier to work with.
Common Virtual Machine File Configuration #2 – External Virtual Machine Data Root
If you do select to “Store the virtual machine in a different location” you will get what we call a virtual machine with an external virtual machine data root.

With this option we create a new folder named after the virtual machine, and set the virtual machine data root and snapshot data root to this folder.  We also default to creating the virtual hard disk in this new folder.

Common Virtual Machine File Configuration #3 – Exported / Imported virtual machine
If you export a virtual machine a virtual machine and then import it without checking the option to “Duplicate all files so the same virtual machine can be imported again”, you will end up with a virtual machine that looks like a virtual machine with an external data root – but there will be one difference.

Instead of having the virtual hard disks stored in the same location as the virtual machine data root – they will be stored in a “Virtual Hard Disks” folder under the virtual machine data root folder instead.
Changing a virtual machine to a default data root virtual machine
If you have an existing virtual machine that you want to change to a “default data root” configuration – the easiest way to do this is to export the virtual machine and then import it and check the option to “Duplicate all files so the same virtual machine can be imported again”.  The resulting virtual machine will be a default data root virtual machine.
Changing a virtual machine to an external data root virtual machine
If you have an existing virtual machine that you want to change to an “external data root” configuration, you have two options:

• Spend some time scripting the import / export APIs in Hyper-V.  It is possible to do it this way – but it is not easy.
• Move the virtual machine using System Center Virtual Machine Manager.  SCVMM will always transform a virtual machine into an external data root virtual machine in the process of moving it.

Changing the snapshot data root for a virtual machine
The only way to change the virtual machine data root for a virtual machine is by using import / export.  But the snapshot data root for a virtual machine can be changed at any time – as long as all snapshots are deleted first.  If you have deleted all existing snapshots you can change the snapshot data root by changing the “Snapshot File Location” setting for the virtual machine under the virtual machine settings user interface.