Want to go for the 70-659 exam? Microsoft is offering a great opportunity to get it done! They are providing FREE workshops to get you prepared.
The 2 day online workshop covers 4 modules of 2.5 hours each, covering all the content of the exam. Get ahead of the crowd, don’t miss it!
Dates available:
18 & 19 April – 9:30 to 14:30
20 & 21 April – 9:30 to 14:30
Good luck!
Bitlocker was designed to work with Windows Vista and Server 2008 and newer versions, but unfortunately some companies are still administering their environments with back ends based on Windows Server 2003 and Helpdesk staff using Windows XP.
In order to do a proper Bitlocker Administration, access to the Password Recovery keys for Bitlocker is critical. It took me a long time to gather all the information required to have access to the Bitlocker keys on Windows Server 2003, so I decided to share it with you!
1. The first step is to extend the Schema of your 2003 Domain to support the Bitlocker AD Attributes.
If you enable Bitlocker on machines before extending the schema the key will not be stored on Active Directory.
Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information:
http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=13432
This download includes a guide, the schema extention and a few additional scripts you will need to run to allow machines to auto-update TPM information.
2. The second step is to install the SP1 for the Windows Admin Tools Pack
Install Windows Server 2003 Service Pack 1 Administration Tools Pack
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3725
3. The third step is to install the actual Bitlocker Password Viewer for Active Directory.
In this case we are talking about a Windows Server 2003 SP1 or later. Unfortunately there is no direct link for this download. The only official way to get that is to log a support call with Microsoft. You might be lucky and find it somewhere else ;D
BitLocker Recovery Password Viewer for Active Directory Users and Computers
http://support.microsoft.com/kb/928202
Extract:
Note: This article also provides information about optional use of the BitLocker Recovery Password Viewer for XP-based computers. If you want to obtain the BitLocker Recovery Password Viewer tool for Windows XP/Windows Server 2003, please contact a Microsoft Support Professional.
The final result – You will get a tab for Bitlocker Recovery on the COMPUTER objects in Active Directory:
One of the things I still can’t understand is why users should be allowed to join computers to the domain. One Best Practice I always follow is to change the maximum number of machines an authenticated user can join to the domain to ZERO.
Users with permissions to create objects on specific OUs, by being Domain Admins or through delegated rights (use the delegation wizard) will still be able to create computer objects, and join computers to the domain.
To accomplish that follow the procedure bellow:
ADSIedit > Default Naming Context > “DC=domain,DC=com” > Properties > Attribute Editor:
Set: ms-DS-MachineAccountQuota to 0
Summary:
ms-DS-MachineAccountQuota stores a numeric value of the number of computers that a user is allowed to join to the domain (actually it is the number of computer objects that that user is allowed to create in a domain). When a machine is joined to the domain, the authenticating Domain Controller searches the domain for all computers previously added by this user and compares that number against the value defined in ms-DS-MachineAccountQuota. If the number of computers created is less than the value defined in ms-DS-MachineAccountQuota then the operation succeeds. If not, the operation fails. Administrative users and delegated users are exempt from this quota because they have the necessary permissions to create computer objects anywhere in the domain, therefore the initial permissions checks succeed. By default, any authenticated user can join up to ten computers to the domain. This is because Authenticated Users has the right “Join workstations to the domain” by default, and because the default value for ms-DS-MachineAccountQuota is 10. Setting ms-DS-MachineAccountQuota to zero, stops authenticated users from joining workstations to the domain.
Requirments: at least 2003 Domain functional level
Reference: http://www.msresource.net/knowledge_base/articles/info:_how_does_ms-ds-machineaccountquota_work.html
Virtualising Servers with Hyper V
Date: Tuesday, 28 February 2012Topic: Cloud
User: IT Pro
Location: Park Plaza, Plaza 3-6 Room, Boar Lane City Square, Leeds, LS1 5NS
The aim of this camp is to provide a practical introduction to Hyper-V, for
people new to server virtualisation or those experienced in other server
virtualisation technologies.
The exact content of each camp is driven by you, the delegate. However, we
will follow some broad topics around virtualisation such as:
I migrated a few machines using ADMT 3.1 from a source Domain A.local to target Domain B.net
I had a few errors with the Agent and it took me a long time to find the solution.
It looked like a DNS issue, as it is the most common cause for failed ADMT agent operations.
The error was ERR3: 7075 (“ERR3:7075 Failed to change domain affiliation”), which drove me to this KB – http://support.microsoft.com/kb/929493
But that was not the solution, as the problem was caused by a specific setting on the Server 2008 Domain Controller policies.
1. The solution: Log on to a Windows Server 2008-based domain controller.
2. Click Start, click Run, type gpmc.msc, and then click OK.
3. In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
4. In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.
5. In the Properties dialog box, click the Enabled option, and then click OK.
Source: http://support.microsoft.com/kb/942564
Happy Migration!
One of the main reasons why Windows is very well established as The Enterprise Operating System is the ease of centralized administration. Most of the credit goes to Group Policies. Group Policies are a set of rules that will be enforced on the workstations and on user profiles. Based on the rules, user experience will change. That means that a CEO will get a more flexible and open system than a call center user, which will get an OS restricted to the tools he needs to be able to perform his tasks.
Group Policy is extremely powerful, and as Uncle Ben told Peter Parker (a.k.a. Spiderman) – ‘With great power comes great responsibility’. The reason I am bringing that up is that is that IT departments overlook the importance of controlling access to Group Policy management. Group Policies are live, as soon as you edit a setting it is already in place. Giving control of group policy to people without the right skills can be very dangerous and can cost the company productivity and financial loss.
As a real life example, I had the opportunity to work with an Education company related to the military services. One of their IT helpdesk people, I will call him Steve, was trying to “open” the internet connection to one of the directors of the business. The Director who was on a resort for a week with his family, wanted to get some work done, and was struggling to connect to the internet. Steve who is a self-tough IT professional uses the tools he feels can address the issue quickly and helps the Director who seemed really happy over the phone. Feeling great because he was able to help a high profile person on the company, Steve goes away to his 2 days off, as planned in advance.
Next morning Steve’s boss Nick can’t access the internet and starts troubleshooting, but it seems that his proxy settings are not being correctly assign and it isn’t long until other users started calling helpdesk about not being able to access the internet. Nick talks to his team and no one knows what might have caused the issue. Steve was away. That is the point when I was called in.
Trying to gather information on symptoms, we identified that the issue was only affecting manages and directors, therefore, very likely to be a proxy setting issue. Trying to get more information I went to the proxy settings on Internet Explorer on Nick’s computer and found that the settings were blank. Nick was surprised that I could even get to the proxy settings as this was a protected menu on IE. This information was enough to find the cause of the issue. Someone, at some point, change a group policy containing a few settings. Looking at the recent changes I could identify which policy was changed the previous day, but not who did it and which settings where affected. The policy name didn’t help much as it was named “Directors and Managers”.
I focused on restoring internet connectivity by specifying the proxy settings, which took over 40 minutes for Nick to find out what is was due to the lack of documentation. I also restricted access to the connections tab on IE.
With the problem resolved and people back to work just after lunch, I had a meeting with Nick. The first question was “What happened?” The answer was easy; someone changed the group policy settings that affect the managers and director. I restored internet connectivity and secured the menu, but can’t guarantee that other settings are on the state that they should be. Than Nick asked, “What can be done to prevent that from happening again?” An my answer was; don’t give more rights to user than they really need, and more specific for this case, make sure that only people who know what they are doing have permissions to manage group policy. You can also use Microsoft Advanced Group Policy Management, part of MDOP, one of the benefits you have because you have Software Assurance on your Windows Licences.
Two days later I get a call from Nick telling me that Steve did it to help a director and he had no clue what he was doing, but then again, he was never trained by the company to do his job properly.
In short, be careful when assigning permissions for IT admin staff, helpdesk, etc. Always give them the minimum rights they need to be able to perform the tasks they are supposed to do. Many companies give “Domain Admin” rights to a lot of people just because it is easier, and that can cause a lot of issues.
Keep it classy IT pros.
Resources:
2008 Group Policy Planning and Deployment Guide
Advanced Group Policy Management Overview
