Running PowerShell under “run-as” or elevated privileges

Standard

There are times when I am in a PowerShell session and pass another set of credentials when I use connect-qadservice cmdlet to connect to another domain with the –credential parameter, however often times I would launch the PowerShell under “run-as” with the elevated credentials and launch a native session and I would have multiple session going at the same time. For latter scenario, I needed a way to identify which is which to adhere to a safe practice. There are probably other ways to tackle this but you can create PowerShell profile in each of your elevated session and change the look and feel as below.

Launch the PowerShell under run-as and run this :

new-item -path $profile -type file -force

notepad $profile

And add the following line into your profile

(get-host).UI.RawUI.Foregroundcolor=”yellow”

You may also want to add a different ‘window’ title for your admin session, you can add this.

$a = (Get-Host).UI.RawUI
$a.WindowTitle = “Admin Session”

Save the changes in the notepad and launch your elevated PowerShell session to see the results.

image

See this for more changes and tweaks you can do to a PowerShell console.

http://technet.microsoft.com/en-us/library/ee156814.aspx

PowerShell : How do I create Trust ?

Standard

A question was raised on ActiveDir regarding the ability to create Trust via a command line utility. It was discussed how netdom is no longer a supported command line utility to create Trusts. I referenced a snip from AD Cook Book using PowerShell to create Trust via the .Net AD namespace method alternatively.(System.DirectoryServices.ActiveDirectory).

You can use following code to create a two-way transitive trust between the local forest and a remote forest. You will have to run this code on the opposite side of the trust in order for the trust to be fully functional.

$localfor=[System.DirectoryServices.ActiveDirectory.Forest]::getCurrent()
$strRemoteFor='remotedomain.net'
$strRemoteUser='administrator'
$strRemotePass='P@ssw0rd'
$remoteCon=New-Object
System.DirectoryService.ActiveDirectory.DirectoryContext('Forest',
$strRemoteFor,$strRemoteUser,$strRemotePass)
$trustDirection='BiDirectional'$localFor.CreateTrustRelationship
($remoteFor,$trustDirection)

Server Core R2 DC promotion fails due to unavailable ADDS binaries

Standard

I encountered an issue promoting a Server Core R2 to a domain controller. The DCPROMO on Server Core is handled via unattended mode with answer file. The error I received is below. It was due to Server Core’s inability to install/confirm ADDS binaries.

C:UsersAdministrator>dcpromo /unattended:answer.txt
Checking if Active Directory Domain Services binaries are installed…
Failed to detect if Active Directory Domain Services binaries were installed. The error was: An error with no description has occurred.

And the DCPROMOUI.log also shed some light on the nature of the issue.

dcpromoui 504.204 001E 03:01:08.709     Unable to find identity string for package name Microsoft-Windows-ServerCore-Package
dcpromoui 504.204 001F 03:01:08.709   Failed to retrieve the parent package name
dcpromoui 504.204 0020 03:01:08.709   HRESULT = 0x800F0818
dcpromoui 504.204 0021 03:01:08.709   HRESULT = 0x800F0818
dcpromoui 504.31C 0022 03:01:08.709     HRESULT = 0x800F0818
dcpromoui 504.31C 0023 03:01:08.709   Enter GetErrorMessage 800F0818

My attempt to add the binaries via the DISM also failed.

dism /online /enable-feature /featurename:DirectoryServices-DomainController-ServerFoundation

Deployment Image Servicing and Management tool
Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Error: 0x800f0818

DISM failed. No operation was performed.
For more information, review the log file.

The DISM log file can be found at C:WindowsLogsDISMdism.log  

The OCSETUP attempt also failed sighting the same error.

ocsetup DirectoryServices-Domain-Controller-ServerFoundation

 

image

 

After I had ensured that the OS was up-to-date with patches and updates, I stumbled upon System Update Readiness Tool KB947821. What is System Update Readiness Tool ? it is a patch that helps you find the inconsistencies with system files.

System resources, such as file data, registry data, and even in-memory data, can develop inconsistencies during the lifetime of the operating system. These inconsistencies might be caused by various hardware failures or might be caused by software issues. In some cases, these inconsistencies can affect the Windows servicing store, and they can cause software updates not to work. The System Update Readiness Tool tries to resolve these inconsistencies.

The System Update Readiness Tool creates a log file that captures any issues that the tool found or fixed. The log file is located at the following location:

  • %SYSTEMROOT%LogsCBSCheckSUR.log
  • %SYSTEMROOT%LogsCBSCheckSUR.persist.log

On this Server Core, the CheckSUR.log indicated issues with two files (its an update specific MUM file with its catalog file), that the tool found to be corrupted.

Checking System Update Readiness.
Binary Version 6.1.7600.20822
Package Version 10.0
2011-02-19 20:53

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs
(f)    CBS MUM Corrupt    0x00000000    servicingPackagesPackage_for_KB2207566_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum        Expected file name Microsoft-Windows-ServerCore-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Summary:
Seconds executed: 165
Found 1 errors
  CBS MUM Corrupt Total count: 1

Unavailable repair files:
    servicingpackagesPackage_for_KB2207566_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum
    servicingpackagesPackage_for_KB2207566_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat

I also came across this Technet forum post, which is similar in nature but is applicable to different corrupt files with different symptoms, however it was this post that gave me the idea to fix my problem.

Solution :

1. I downloaded the KB2207566 (Windows6.1-KB2207566-x64.msu) as indicated by SUR log, and copied it to Server Core (c:temp). Note that this patch already had been installed but for some reason had the mentioned files corrupted.

2. I then extracted the MSU file into a sub folder and extracted the *.cab files.

C:UsersAdministrator>cd c:temp

c:temp>wusa Windows6.1-KB2207566-x64.msu /extract:c:servicingkb2207566

c:temp>cd kb2207566

c:tempkb982214>mkdir files

c:tempkb982214>expand Windows6.1-KB2207566-x64.cab -F:* files

The two files I had to replace were these :

image

The location for the existing files that had to be replaced was c:windowsservicingpackages and an issue I ran into, as it was indicated on the Technet post (when I simply attempted to UNC and copy from another regular W2K8 machine) was that these were protected files and the copy/create option was denied. Lot of systems folders/files in Windows 7 and Windows Server 2008 have a different owner than ‘administrators’ and the TrustedInstaller is set as owner and has full control rights set.

image

3. And I then opted to use the command line option to take the ownership of the folder and assign ‘administrators’ the full rights on the Server Core.

takeown /f c:windowsservicingpackages /r /d y

icacls c:windowsservicingpackages /grant administrators:F /T

4. And lastly I copied the extracted files and replaced.

C:tempkb982214files>copy "package_for_kb2207566_rtm~31bf3856ad364e35~amd64~~6
.1.1.0.cat" c:WindowsservicingPackages

Overwrite c:WindowsservicingPackagespackage_for_kb2207566_rtm~31bf3856ad364e
35~amd64~~6.1.1.0.cat? (Yes/No/All): y
      

1 file(s) copied.

C:tempkb982214files>copy "package_for_kb2207566_rtm~31bf3856ad364e35~amd64~~6
.1.1.0.mum" c:WindowsservicingPackages

Overwrite c:WindowsservicingPackagespackage_for_kb2207566_rtm~31bf3856ad364e
35~amd64~~6.1.1.0.mum? (Yes/No/All): y

1 file(s) copied.

No restart was required and the DCPROMO with the answer file succeeded as it was now able to install the ADDS binaries and the DC promoted successfully.

Note that prior to the fix I also noticed that I was unable to enable the remote management from the SCONFIG (option 4, sub option 3) which also worked afterwards.

Exchange 2010 Setup and .Net Framework 3.5 SP1 Requirement

Standard

Starting with Exchange 2007, the good thing about the setup wizard is that it guides you about all the pre-requisites and provides the links from where you can download them from.

image

However, if you are installing Exchange 2010 on Windows Server 2008 (or R2) box, and if you follow the link provided by the wizard and download the general .Net Framework 3.5 from MS Downloads you are likely to get the error “You must use the Role Management Tool to install or configure Microsoft .Net Framework 3.5” upon installing it.

image

As the .Net Framework 3.5 is bundled in as a “feature” and you must add it from the Server Manager/Features snap-in (formerly add/remove programs). This should not be only pertinent to Exchange but would be applicable to all other apps that require .Net Framework 3.5)

image

PowerShell : How do I find all DCs in my forest ?

Standard

 

I find the –computerrole parameter of Get-QADComputer handy to find DCs and when usually I have to retrieve something from them with a WMI query, pipeline to (GWMI),  Here is a quick way to retrieve all DCs in a multi-domain forest model using the .NET namespace i.e [DirectoryServices.ActiveDirectory.Forest] method.

To find Global Catalogs only;

[DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest().GlobalCatalogs | ft name,OSVersion,Domain

To find all domain controllers;

[DirectoryServices.Activedirectory.Forest]::GetCurrentForest().domains | %{$_.domaincontrollers} | ft name,OSVersion,Domain

 

To find out what other information you can retrieve from the DCs via this method simply pipe to the Get-Member Cmdlet;

[DirectoryServices.Activedirectory.Forest]::GetCurrentForest().domains | %{$_.domaincontrollers} | Get-Member

 

image