Long time no post... over the last year I have been working on a global
ConfigMgr Implementation coupled with Adaptiva OneSite.
Adaptiva OneSite as a product is excellent, however the documentation at
this stage is somewhat lacking, therefore I am taking the time to blog my
discoveries over the past year with regards to the product for the benefit of
myself and others.
This will be in no particular order, rather just a collection of thoughts /
findings around real world usage of the product, enjoy :)
Cheers
Wayne
Most Popular Posts
Tuesday, 9 June 2015
Sunday, 4 May 2014
How to: Simulate multiple subnets in A single box Hyper-V Lab
As the title suggests this post will show you a quick and easy way to setup multiple subnets in a lab environment whilst maintaining internet access for all of your virtual machines.
Note: All of the machines I am using are running Windows Server 2012 R2. I will explain how I have mine setup so you may adapt your setup to suit.
I have a box called RRAS01 with 3 vNICS setup as follows:
On your RRAS Server launch the add roles and features wizard and choose the Remote Access server role, then on the select role service choose Routing which will in turn select the DirectAccess and VPN role, follow the wizard through allowing it to complete.
Once complete reboot the server. Ignore the getting started wizard in server manager and just launch the Routing and Remote Access MMC snap-in from tools, start the RRAS server if necessary and that should be it, you should now be able to ping across both subnets and access the internet from both subnets.
Its a very crude way of doing it, I suppose if you wanted a 3rd subnet you would add another vNIC to the RRAS Server and take it from there, however it works and helps us simulate multiple subnets in a lab environment.
Wayne
Tuesday, 25 February 2014
ConfigMgr 0xc0000359 error code on Generation 2 UEFI machine
I came across a strange issue today whilst working with a colleague I met on a project.
He was trying to build a new x64 generation 2 virtual machine using ConfigMgr 2012 R2 but it was failing with the following error:
File: \Windows\System32\boot\Winload.efi
Status: 0xc0000359
We noticed that upon hitting F12 to boot the machine was pulling down the x86 boot image. At this point the machine was unknown to ConfigMgr, and our unknown computers collection had 2 task sequences advertised - Windows 8.1 x64 and x86
So we disabled the x86 task sequence and voila! it booted from the x64 wim, We then re-enabled it and it booted from the x86 wim.
Not happy with this behaviour I dug a little deeper......
SMSPXE.log told us the deploymentID it had selected ended in 20017 and this gave me an idea, we turned to Deployments under the Monitoring workspace in the ConfigMgr console and viewed the DeploymentIDs of our 2 task sequences.
We noticed that the x86 one ended in 20017 and the x64 ended in 20016, it seemed that the newer DeploymentID of the two was taking precedence....
We tried it again and it pulled down the x64 wim file this time! Result!
To be sure this was the cause we then did the same with the x86 task sequence (deleted and re-deployed it) and sure enough it pulled down the x86 wim file.
So long story short: Deploy your x64 task sequence last if you are deploying more than one task sequence to a collection
Cheers
Wayne
He was trying to build a new x64 generation 2 virtual machine using ConfigMgr 2012 R2 but it was failing with the following error:
File: \Windows\System32\boot\Winload.efi
Status: 0xc0000359
We noticed that upon hitting F12 to boot the machine was pulling down the x86 boot image. At this point the machine was unknown to ConfigMgr, and our unknown computers collection had 2 task sequences advertised - Windows 8.1 x64 and x86
So we disabled the x86 task sequence and voila! it booted from the x64 wim, We then re-enabled it and it booted from the x86 wim.
Not happy with this behaviour I dug a little deeper......
SMSPXE.log told us the deploymentID it had selected ended in 20017 and this gave me an idea, we turned to Deployments under the Monitoring workspace in the ConfigMgr console and viewed the DeploymentIDs of our 2 task sequences.
We noticed that the x86 one ended in 20017 and the x64 ended in 20016, it seemed that the newer DeploymentID of the two was taking precedence....
So we deleted the x64 deployment and recreated it, which then gave it a higher DeploymentID than the x86 task sequence (below)We tried it again and it pulled down the x64 wim file this time! Result!
To be sure this was the cause we then did the same with the x86 task sequence (deleted and re-deployed it) and sure enough it pulled down the x86 wim file.
So long story short: Deploy your x64 task sequence last if you are deploying more than one task sequence to a collection
Cheers
Wayne
Saturday, 8 February 2014
Replace failed disk in Areca raidset
A quick post on how to replace a failed disk in an Areca raidset:
Replace the faulty disk in the server, power up and launch the web admin console. Once open and logged in expand RaidSet Functions | Create Hot Spare
Set the new disk as a hot spare and you should see "Rebuilding" in the web console :)
Replace the faulty disk in the server, power up and launch the web admin console. Once open and logged in expand RaidSet Functions | Create Hot Spare
Set the new disk as a hot spare and you should see "Rebuilding" in the web console :)
Wayne
Subscribe to:
Posts (Atom)

