Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts

Thursday, 11 July 2013

How to Uninstall SCCM 2007R3 Secondary site

I couldn't find any formal step-by-step guidance on this so I decided to create my own. I believe that below is all that is nessecery to completly remove the secondary site from the SCCM console. I've had to do this in situations where the the site is no longer required, or has to be rebuilt due to issues.


1.       Navigate to “site database” > “site management” > Select the site you with to uninstall.

2.       Browse to boundaries under the site and remove any active boundaries by right clicking and choosing “delete”.

3.       Reboot the secondary site.

4.       Open an Active Directory Users and Computers MMC

5.       Connect to the local domain controller at the location of the secondary site.

6.       Enable Advanced Features.

7.       Browse to : “System” > “System Management”
Verify that the entries for the boundaries you removed have disappeared from AD. (The OU will stay in there until the site is deleted but the address boundaries should disappear.


 

9.       Navigate to “site database” > “site management” > Right click on the secondary site you wish to uninstall.

10.       Follow the wizard through and select either delete or deinstall as appropriate to your situation.
 
 

11.       Click Finish.

12.       Monitor the logs for the primary site, when you see the below highlighted message the uninstall is completed.
 

13.       Right click on site database and click “refresh”. Verify that the site has disappeared from Site Management.

 

14.       Go into “site Database > Site Management > Your Primary site > Site Settings > Addresses” locate the old “standard address sender” with the old site code and right click on it and delete.

 
This won't leave the deleted secondary server in a completly "clean" state - any updates to SCCM you applied, hotfixes and package source folders will remain on the server. I would recomend doing a clean OS reinstall on this server before utilising it for any other purpose.


Friday, 20 January 2012

Resolving Active Directory Account Lockouts


Account lockouts can be a real pain to fix if you don't know where the lock is coming from. In these days of mobile computing very few users restrict themselves to a single PC or device. Often IT departments have to allow multiple devices to utilise the same user account credentials whether that be on the company Desktops, Laptops, Smartphones or even home user equipment. The problem is that when you have so many devices it gets a bit tricky to see where the lock has come from and users inevitably begin to think there may be some kind of conspiracy against them when their account keeps locking; even if it is their fault!

Tools Required


To perform all steps in this guide you will require a few tools:
A PC with Admin Pack installed (for Active Directory access) and Acctinfo.dll installed
(http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465)


Causes of Account Lockouts

The most obvious scenario is that the user is continuously inputting the incorrect username/password combination - but that's far to easy. Other scenarios include:


  • The user has changed passwords once they have logged on but have not logged back on again to re-sync their account.
  • A stored username/password in a program, perhaps one that requires separate proxy authentication is requesting access to the Internet and supplying an incorrect password.
  • A third party device, such as an Iphone connecting to webmail via RPC over HTTP with the incorrect password stored.
  • The user has mapped a network drive on a different machine using their credentials and choose “Save Password” option, which has now expired.
  • A scheduled task running with an invalid password.


Finding Where the Account Lockout Originated

The first thing is to make sure you know where the account lockout is coming from. Use Active directory with the ACCTINFO.DLL tab and check the time of the last “bad logon”.



Clicking on “Account Lockout Status” will bring up a list of domain controllers, allowing you to ascertain which domain controller the user locked out on first.





Right click the domain controller the account locked out on and choose event viewer, then organise by user and click on the username. You will see a "Failure Audit" at the time of lockout.


 
You will then be given the name of the machine the account has locked out on as well as an Idea what program may have caused the lock, see “Logon attempt by” field.





Sometimes this can be a very generic system process which will result in you having to perform further troubleshooting steps on the user’s machine.


Finding the Cause of the Lockout on the User Machine


Finding the cause of account lockouts on the local machine can be quite difficult due to the number of potential causes of this problem but some general advice is as follows:


  • Clean out the Temporary Internet Files and stored passwords in Internet Explorer.
  • Clean out the windows credential manager by running "Control keymgr.dll" from the run prompt and deleting all stored passwords.
  • Check the users “My Computer” for drive mappings created by the user; if there is anything out of the ordinary remove the mapping.
  • Check for unusual software that may require individual proxy server configurations such as Google Earth, or any programs that perform periodic updates.



Drastic Measures if you still can't find the lock


From the Account lockout tools copy alockout.dll to the user’s c:\Windows\System32 folder. Remotely connect to the users registry using regedit and navigate to this key:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows


Create a new REG_SZ key called "AppInit_DLLs" and set its value to “alockout.dll"




Now restart the PC and wait for the account to lock out again. Once it locks check the C:\WINDOWS\Debug folder for a file called “Alockout.LOG”.

If you open this file with Notepad you should see a list of applications which attempted to pass network credentials along with details on which was successful and which failed. Check what time the users account locked out in ACCTINFO.DLL and the look for the corresponding entry on the list, this will be the application causing the problem.

The final step is to find this application on the user’s computer and find a way to either remove the cached credentials or in worst case scenario it may be necessary to remove the program all-together.

Sunday, 18 December 2011

Removing local admin accounts except for Jim and Bob

As far as I can remember it's been recommended good practise to remove local administration rights from end-users PCs, but if you haven't already done this or haven't quite got everyone in your department on-board with the idea It can be a tricky business explaining to your users why you have to remove that BitTorrent client and their favourite spyware ridden game from their business machine. What about Jim and Bob, the directors of your company? Effectively it's their train set, they pay your salary and pretty much own the business. Are you really in a position to be able to tell them what they can or can't do on a company PC? Them having their own apps installed inevitably this leads to a infection where all lower-level managers below them want the same. Before you know it you become inundated with requests for questionable software to be installed and end up actually having to support it, congratulations, you now support an app you know nothing about, have no mention of it in your service catalogue and no Service Level Agreement.

In an ideal world the best solution to this is not to allow them to install it in the first place, which is fine if you are in a position to take this firm standpoint and treat all users the same. Unfortunately a few weaker links inevitably end up making more work for you and everyone else.

Group policy will allow you to create security groups for your elevated accounts and can also be configured to strip out other accounts from local administration groups. This is fine if everyone is on-board with the idea and you don't want to end up with several policies for different types of users.

The solution I came up with will allow you to remove all unauthorised users accounts, both domain and local from the computer administrators group but will allow you to add your elevated accounts and have a list of exceptions that won't be removed. This means Jim and Bob and those rare but pesky applications that just won't work properly without local admin privileges can still work, and you have clear visibility of who actually has these rights.

The script below was based on another script I found that would just remove all local admins, I've modified it to allow exceptions, and to add in the relevant elevated account groups. Keep reading for instructions on how to implement it into your environment.


' Remove Unapproved Local Administrators.
' Last update 28/10/11 by Andrew Allison
' vbscript


'** check os version first
strComputer = "."
Set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMI.ExecQuery("SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem in colItems
osversion = (objItem.Caption)
targetos=("Microsoft Windows XP Professional")
intCompare = StrComp(osversion, targetos, vbTextCompare)
'wscript.echo targetos
'wscript.echo osversion
'wscript.echo intCompare
if intCompare = -1 Then
wscript.echo "Do not use your standard user account to log onto servers! Use your Elevated account."
wscript.quit
elseif intcompare = "1" Then
wscript.echo "Do not use your standard user account to log onto servers! Use your Elevated account."
wscript.quit
else
'wscript.echo "0 - it must be good old XP - lets rock!"
end if
next

'** Define Variables
    Dim PermittedAdmins' As Array
    Dim group
    Dim network
    dim fourthletterinname
 
   
'** Define Permited Administrators List
PermittedAdmins = Array("Administrator", "Domain Admins", "Director1", "Director2", "GPO_LAPTOP_PCADMIN", "GPO_DESKTOP_PCADMIN) '<--- Add to this Array any additional permited admins


'** Get Local Administrator Group
    Set AdminGroup = GetObject("WinNT://./Administrators, Group")

'** Search for Invalid Members & Remove Them
    For Each GroupMember in AdminGroup.Members
   
        Debug.WriteLine GroupMember.Name, GroupMember.Class, IsPermitedAdmin(GroupMember.Name)
   
        If Not IsPermitedAdmin(GroupMember.Name) Then
            AdminGroup.Remove GroupMember.ADsPath
        End If
    Next

'** Functions *****************************************************************
    Function IsPermitedAdmin(MemberName)' As Boolean
        Dim i' As Long
       
        For i = LBound(PermittedAdmins) To UBound(PermittedAdmins)
            If UCase(MemberName) = UCase(PermittedAdmins(i)) Then
                IsPermitedAdmin = True
                Exit Function
            End If
        Next
       
        IsPermitedAdmin = False
    End Function


'**Start adding PCadmin groups
Set wshShell = WScript.CreateObject( "WScript.Shell" )
strComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
Set network = CreateObject("WScript.Network")
Set group = GetObject("WinNT://" & network.ComputerName & "/Administrators,group")
On Error Resume Next 

fourthletterinname = Mid(strComputerName,4,1)
if fourthletterinname = "D" Then
group.add("WinNT://yourdomain/GPO_DESKTOPS_PCADMIN")
Elseif fourthletterinname = "L" Then
group.add("WinNT://yourdomain/GPO_Laptops_PCADMIN")
else
'do nothing
end if
On Error Goto 0
wscript.quit


Note as per the "check OS version first"  section  you can see in the above script I have specified that this script should only run on a singular operating system, Windows XP Professional. This can be easily changed to any other operating system. The purpose of this function is that in all likelihood you don't want this script to end up running on your server operating system, although it is entirely possible to add all your local server administration accounts too. If you don't want to use the OS check, simply remove this section.

The "Define Permitted Administrators List" section is where you will want to put in the user name of your PC Admin management groups and also your pesky exceptions. This isn't a list that will add admin groups, this is a list that the script will NOT remove.

Another part you may want to remove or modify is the "Start adding PC admin groups" - this is the function that will insert your Active Directory PC Administration groups into the PCs local administrator group. In my environment all devices follow a strict naming convention which is SITE-MACHINETYPE-ASSETNO-USER eg: SBPD12345ALLISA the "fourth letter in name" variable is used to hold the fourth letter in the machine name, as you can see this will be either D for desktops, or L for laptops. If you only have one admin account for every type of device you can modify this to only have one group, this function just give a little more granular type of security.

OK, now you have the script and have modified to suit your environment, but how do I deliver it onto the PCS? Group policy is the key here.

You have two choices here, you can either apply based upon machine-based-policy or user-based-policy. There are advantages and disadvantages of both. In my environment my manager requested this be done on user policies. Create a new policy or modify an existing one and navigate to "scheduled tasks".


Right click and create a new scheduled task. The settings here are up to you but this how I have configured mine.

It's up to you as to where you store the script, you could in effect deliver it to each machine, or leave it on a web-server. I personally have opted to put it into the domain SYSVOL folder on my Domain Controller. Ensure that you use an account on the scheduled task with sufficient access to manage your PC admin group. I like to run set the script to run at logon to remove unwanted "tweakers" ;-)




All of this is pointless if you fail to maintain your Active Directory PCADMIN groups, don't allow unelevated accounts to be added to these groups, the last thing you want to do is to give your director rights to install software on every PC on the network rather than just his own. Use the exclusions wisely.

Andrew


Thursday, 15 December 2011

After all these years IE7 is still giving me a headache

At the moment the company I work for is in a transitional phase between switching from our old Windows XP environment managed by Altiris Deployment Console to a new environment which will utilise Windows 7 Enterprise x64 and SCCM 2007 R3. I've been the tasked with being the technical lead on the implementation of SCCM and also have been working away on creating the Windows7 build and SCCM OSD task sequence. At the moment the build is almost finished, but there are still several issues being found by our IS pilot team. Due to the issues and the scale of the task required to ensure compatibility with older systems we are taking our time trying to get it right. The other major piece of work we have is a full Active Directory and group policy restructure, all of these things take time and require in-depth knowledge of how each department in the business will use the new software you will provide.


Just now I'm left working with two different AD/GPO structures and two user operating systems to support and it's proving to be a headache. Luckily, one of the smartest things we did was to put a freeze on change control to the old environment, but this means that we are stuck with older software such as IE7, with no way to upgrade without breaking compatibility with older browser based add-ons and custom intranet solutions powered by Workflow on Lotus Domino. All of these issues take time to fix and our full Windows7 rollout can only be started once Workflow has been replaced by SharePoint.


Some people who don't work for large organisations will say "Pleh! Just do the upgrade" but my business environment does not allow us to make changes on a whim. It's amazing how complicated changing something as simple as a browser plugin can be when you have 2000 users breathing down your neck if it doesn't behave exactly as it used to!


Today the issue I had was with IE add-ons. A call came in via the service desk and they were unable to resolve. The call originally was logged as "Flash player doesn't work". The service desk had tried to install the latest version by using an Altiris job I had prepared earlier, it seemed to install fine but when the user went onto YouTube it asked them to install the latest version of Flashplayer.  It didn't take me long to check the add-ons menu and find that all add-ons are marked as disabled and marked as being "managed by your administrator". Strange, I don't remember setting that in a group policy, so I reset all IE settings to default, same issue. I went to the run prompt and started iexplore.exe in case it was running with in no-addon mode and it wasn't. I then checked the machine and user OU to see what policies had applied to the system and then checked the relevant group policy, no sign of add-ons being managed by policy. I logged off as the user and on as my domain admin account and found add-ons still disabled and greyed out. This was starting to become a head scratcher, I decided to follow a process of elimination and remove IE add-ons that may have become corrupted, after I ran out of add-ons to remove I still had the same issue - no luck! Next idea, a uninstall and reinstall of IE7, to make matters worse I am in Glasgow, Scotland and the system in in Sydney, Australia - the remote control speed is abysmal and I know that a reboot will be required to complete the IE re-configuration; this is a major problem since this was a laptop with a power on password enabled at bios level and no user available at the other end to type it in.


At this point I delayed the reinstall/repair idea and went to the registry and mess around for 15 minutes. A quick trip to TechNet and I'm no better off, I find a key on TechNet all pointing to:


HKLM \SOFTWARE\Policies\Microsoft\Internet Explorer\Restrictions 
NoExtensionManagement DWORD set to 1 and not 0.

But these settings are not present on my system. After reading a few blogs I still can't find anything so it's back to regedit. Eventually I found this key :

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\EXT
Restricttolist DWORD was set to 1 when it should have been set to 0.

Just in an instant Its working fine and I'm left wondering how the heck this could have been set to 1 in the first place, why this isn't documented anywhere? I will be really glad to see the back of IE7.

Andrew