Ondrej Žilinec – IT Blog

At one Microsoft Exchange 2010 server I was receiving too many events number 106:

This event basically describes problem with some performance counter. I had problems with about 10 performance counters and I didn’t want to deal with them separatelly. Exchange 2010 has definition its performance counters stored in directory “C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\”. There are XML files which define performance counters. Before you can manipulate with performance counters you need to run Exchange Management Shell and run in it following command:

add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

This Snap-in allows you to use two Cmd-lets:  Remove-PerfCounters and New-PerfCounters. So let’s do two things which help us to get rid of events 106:

Deregister all performance counters for Exchange:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf>dir *.xml | foreach { Remove-PerfCounters -DefinitionFileName $_.Name }

Register all performance counters for Exchange:

[PS] C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf>dir *.xml | foreach { New-PerfCounters -DefinitionFileName $_.Name }

Since I reregistrered all performance counter definitions into Exchange 2010 server I have no problem with event 106.

This was quickie for today 🙂

I always don’t remember commands to list all FSMO roles in domain so I decided to take a quick note into my diary 🙂 :

• Connect to domain controller
• run ntdsutil
• write roles
• write connections
• write connect to server SERVER_NAME
• write q
• write select operation target
• write list roles for connected server

More sexy command is

netdom query /domain:DOMAIN_NAME fsmo

and viola. I know it’s dummy post, but I had to wrote it down 🙂

Today I had problem on one server Windows Server 2008 R2. This server logged error 800B0001 with Windows Update Client:

When I looked at event viewer I saw same error:

and WindowsUpdate.log logged following:

I knew about one issue which is described in this article. But this article didn’t help. When I looked for file C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab, I found out there isn’t such a file. I copied this file from other server Windows Server 2008 R2 and now everything works fine 🙂

So in Microsoft world .cab file is not trusted if it doesn’t exist! 😀 Coool.

ADFS deafult changes language of its pages based on language sent from user’s browser. User’s browser sends http header called Accept-Lanaguage. This means that if, for examle, user with Regional settings set to Slovak accesses ADFS website, all pages are in Slovak language. When someone else comes with Regional settings set to English, all pages are in English language.

There was a need for one ADFS portal I implemented to change ADFS websites’ language to one static language – Slovak (multilanguage option shoule be set off). I digged into ADFS files stored deafult at C:\inetpub\adfs\ls\. After couple minutes I found file called Global.asax.cs which contained something about languages. After coulpe minutes trying to understand .NET I figured out what have to be done to change language to Slovak.

On line number 45 I found following line:

I changed this line to:

Since then everything works only in Slovak language. Just a remark: if you are using ADFS Proxy you have to change this settings on ADFS Proxy server. It doesn’t have to be changed on ADFS server (non-proxy).

Couple days ago I wrote about Remote Assistance. I wanted to make this feature as close as possible to administrators so I decided to implement special item in context menu of ADUC. Let’s do it.

We need to prepare script first. I wrote very simple one:

==========

‘
‘ Script to run Remote Assitance on domain computer
‘

Set wshArguments = WScript.Arguments
Set objUser = GetObject(wshArguments(0))

‘
‘ Check if Remote Assistance is installed
‘

Set fso = CreateObject(“Scripting.FileSystemObject”)
If (fso.FileExists(“C:\Windows\System32\msra.exe”)) Then
 ‘ Is istalled
 Set objShell = WScript.CreateObject(“WScript.Shell”)
 Return = objShell.Run(“C:\Windows\System32\msra.exe /offerra ” & objUser.dNsHostName, 1, true)
Else
 ‘ Is not installed, error.
 Wscript.Echo “Microsoft Remote Assistance is not installed on this machine.”
End If

==========

Let’s save this script as .vbs file into \\DOMAIN.LOCAL\NETLOGON directory. Now when we have a script, we need to create context menu in ADUC. This can be accomplished using ADSI Edit tool. Start ADSI Edit tool and look for CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=domain,DC=local. There look for CN=computer-Display. Right-click on CN=computer-Display and select Properties.

In attribute adminContextMenu add following line:

2, &Remote Assistance,\\domain.local\NETLOGON\RemoteAssistance.vbs

Description:

2 – order number

&Remote Assistance – name of the item in context menu

\\domain.local\NETLOGON\RemoteAssistance.vbs – command to run

When you click OK, OK in ADSI Edit your work is done. Now when you click on computer account you can see and use following context menu item:

And that’s all folks.