I’m in the process of configuring DPM to back up my Hyper-V environment, which resides on an EqualLogic PS6500ES SAN.
It was during this that I encountered an issue with the DPM consistency check for a 3TB VM locking up every other VM on my cluster, due to high write latencies. During this period I couldn’t even get useful stats out of the EqualLogic because SANHQ wouldn’t communicate with it and the Group Manager live sessions would fail to initialize.
After some investigation, I did the following on all my Hyper-V hosts and my DPM host:
- Disabled “Large Send Offload” for every NIC
- Set “Receive Side Scaling” queues to 8
- Disabled the Nagle algorithm for iSCSI NICs (http://social.technet.microsoft.com/wiki/contents/articles/7636.iscsi-and-the-nagle-algorithm.aspx)
- Update Broadcom firmware and drivers
Following these changes, I still see very high write latency on my backup datastore volume, but the other volumes operate perfectly.
I’m currently in the process of upgrading a standalone Server 2012 machine running Hyper-V to Server 2012 R2.
Due to resource constraints, I’m performing an in-place upgrade, despite this server residing 800km away from me. Thank goodness for iDRAC Enterprise.
However, during this process, during the “Getting Devices Ready” section I received a Blue Screen Of Death, with the error message:
After it hit this BSOD twice, the upgrade process failed out and reverted back to Server 2012. I was unable to find a log file of what occurred in any more detail, and was worried that I would be stuck on Server 2012.
Thankfully, I discovered a log file on the iDRAC with the following message:
A bus fatal error was detected on a component at slot 1.
This triggered my memory, and I recalled that we have a USB3 PCI-E card installed for pre-seeding an external drive with backup info.
I used the BIOS setup (Integrated Devices > Slot Disablement) to disable Slot 1, and then retried the upgrade with fingers crossed.
I have never attended Microsoft TechEd, but I REALLY want to, especially after seeing the sheer number of sessions that are relevant to me in 2013.
I’ve been keeping an eye on the TechEd website for some time after the event closed, watching for the posting of the recorded sessions, and now they are up, all 60 something pages of them.
I’ve gone through the list of every session, and collected a link list of 59 of them I want to watch, with some standouts like:
- Windows PowerShell unplugged
- How many coffee’s can you drink while your PC starts
- DFSR 2012 R2 enhancements
- Storage Efficiency with Dell and Storage Spaces
- Mark Russinovich on Cloud Computing
- Upgrade your IT skills and Infrastructure: Cloud Computing
- Performance Optimize your ASP.NET
- O365 Identity Management
- What’s new in Windows 8.1 Deployment
- Hyper-V Recovery Manager
- Backup Strategy for Private Cloud
And so much more…
One of the other major deployments I’ve done recently has been a refresh of all our Autodesk products to the 2014 version. In scope this was smaller than my Office 2013 deployment, however it was much more complicated.
First, I created Active Directory groups to contain the computer accounts of workstations needing a product. For example, a group for AutoCAD 2014 Network license containing computer accounts that required it for installation.
These groups were then targeted with Group Policy Objects which set a scheduled task to run the installation script at 3:00am. Due to the size of the installation, I don’t want to have this run as a startup script.
Next I needed to create the installation script.
To start, I created an Autodesk deployment through Setup.exe. This is typically how standardized installations of Autodesk products are performed, but usually aren’t enough to have a user fully set up.
I began with a deployment of Infrastructure Design Suite Premium (IDSP) since it was 40GB and contained the install files for every ‘lower-tier’ product we were going to install. This way you can use a single source of installation files but multiple configured deployments.
Once the deployment package was created, I put it into a VBS script with a WHOLE lot of other logic.
My installation script can be downloaded here: AutoCAD_2014_Network_Install(rename to .vbs)
The Uninstall Products script can be downloaded here: UninstallProducts(rename to .vbs)
The Copy Fonts script can be downloaded here: CopyFonts(rename to .vbs)
The script can be summarized as follows:
- Check default gateway on the NIC, and if matching branch offices change the install source
- Check for the acad.exe file in the installation directory, and proceed if it doesn’t exist yet
- Run the UninstallProducts script to remove previous versions of software
- Run the Autodesk deployment through the .lnk file created from Autodesk setup.exe
- Begin a loop which checks for setup.exe in the running processes.
- Wait 2 minutes before proceeding with the loop
- Once setup.exe is no longer running, continue by deleting unnecessary shortcuts
- Add extra shortcuts that point to a specific ARG file for customizations
- Install additional programs (AcroPlot PDF software in this case)
- Run the CopyFonts script, passing in the Fonts path for this particular product
- This copies required fonts to C:\Windows\Fonts and the installation directory
- Check again for acad.exe, and if it now exists then log success, otherwise log failure.
Our parent company from a recent acquisition handles it’s deployment in a way that doesn’t meet our requirements, since it is user-based rather than computer based which we require.
There were a few things we had to define for this to be a successful project:
- Installation must run under admin privileges (which our users do not have)
- Ideally, installation should not interrupt or delay a user, but if necessary it is acceptable
- Install source should be dynamic to allow for different branch locations
- Success or failure should be logged to a central file
Based on the above, I came up with a combination of scripts which are reproduced below.
Overall the project was a success, with the only major issue being users not reading instructions (even openly admitting this fact) which caused a huge increase in IT Support requests.
1. Group Policy Objects
I set up two GPO’s to perform two separate functions:
- One to create a Scheduled Task that runs once at 3:00am, executing the install script
- One to execute the install script as a Startup Script under the Computer Configuration settings for all workstations in our area of AD
Using this method, any computer powered on at deployment date would receive Office 2013 at 3:00am without user interruption, and any other computer after that would receive it at startup. The majority of our staff working in an office were not interrupted, and our field staff would all receive the software eventually.
2. Installation Script
My commented installation script can be downloaded here: Office2013InstallStatus (rename to .bat)
In essence, here is what it does:
- Begin by defining location variables that will apply to all PCs by default
- Check matching NIC gateway addresses for offices without an Apps repository and overwrite the location variables if necessary
- This will ensure that all installation files come from a local source
- Note that the LogFile variable is not changed; central to all installations
- Next a check occurs for Office 2013 installation
- If this returns true, the script will exit without further action
- If Office 2013 isn’t already installed, installation will begin
- First write a registry entry on the PC which can be referenced by the Install Status Script (see below) if the user happens to log on during installation
- Uninstall Office 2010 (a straight upgrade has been known to cause problems)
- Uninstall Office 2013 (this will apply to PCs which had ONLY Lync installed)
- Install Office 2013
- Write result to a Log File
- Reset the registry entry of installation status to signify end of installation
- Exit script
3. Install Status Script
Because many of our installations would take place at computer Startup (the second GPO) and it would be possible for users to log onto the computer before the installation is completed (because Windows 7 doesn’t run startup scripts synchronously), I needed a way to tell the user not to open Office products while the installation was running.
My status script can be downloaded here: Office2013StartupScript (rename to .vbs)
This script is placed within all users Startup folder in the start menu, and performs the following:
- Read the InstallingStatus value from the registry which would be set by the Office2013StartupScript.bat script
- If the Status = 0, exit the script. If it = 1, begin a Do loop
- While in the loop, check for the status of the registry key again
- If Status = 1, display the HTA application. This has a timeout of 5 minutes, after which the loop will resume
- If Status = 0, the loop ends and a final message is displayed to the user
One problem we did encounter (which isn’t really resolved yet) is that occasionally the Office 2013 installer would auto-reboot. When this occurred, it interrupted this status script, causing the “installingStatus” flag to remain active. On the next reboot, the Status window would re-appear even though no installation was taking place.
4. Install Status Window (HTA)
The HTA file I’m using to display to the user, called from the Status Script, can be downloaded here: Office2013_message(rename to .hta)