Archive

Archive for the ‘Microsoft’ Category

Changing Registry entries on multiple systems with PowerShell and Remoting

June 12th, 2012 2 comments

 

A few weeks ago, a colleague asked if I knew of a way to script the change or modification of the Registered Owner / Organization information on a Windows Server system (2003 or 2008). I knew that this could be achieved with PowerShell and had some initial ideas, so I spent a few minutes whipping up the script below.

For this to work, you should ideally have all systems on the same Windows Domain and have enabled PowerShell remoting on each system that needs to be changed. Of course you could also just run the script on a single workstation/server on its own without the need for PSRemoting.

 

# On all remote machines that need their info changed
Set-ExecutionPolicy RemoteSigned
Enable-PSRemoting # Say yes to all prompts
#region This part only needed if machines do not belong to the same domain...
# Note: This can be a security risk, only use if you are sure you want to allow any host as a trusted host. (e.g. fine for lab environments)
cd wsman::localhost\client
Set-Item .\TrustedHosts * # Say yes to all prompts
#endregion
# Run on your management machine/machine you are using to update all others...
$computers = @("SERVER1","SERVER2","SERVER3")

foreach ($computer in $computers) {
    Enter-PSSession $computer
    cd 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion'
    Set-ItemProperty -Path . -Name "RegisteredOwner" -Value "Auth User"
    Set-ItemProperty -Path . -Name "RegisteredOrganization" -Value "Lab"
    Exit-PSSession
}

 

So the above should update your registered owner and organization details for each server listed in the $computers array. (Specify your own host names here). The above script should be easy enough to modify if you are looking to change other registry entries. Finally, don’t forget that you should always be careful when updating registry, especially via script – make sure you have backups!

 

Windows Server 8 first impressions (running in VMware Workstation 8)

March 2nd, 2012 No comments

 

I enjoy trying out new Operating Systems as soon as they are released, so naturally I had to download Windows Server 8 Beta Evaluation last night when I had an hour or so to spare.

 

I have installed it in a VM running on VMware Workstation 8.0. The requirements don’t seem to be too high with the most notable resource requirement to me being 512MB RAM. Not much has changed there since 2008 R2 then. The VMware set up was as simple as I imagined – no need to follow any guides, I just went with my gut and created a new VM as a Windows Server 2008 R2 – 64 bit machine, gave it a couple of GB RAM and vCPUs then told it I would install the OS later. After this I added the ISO for the Beta and Powered Up. The Windows 7 desktop wallpaper “fish” makes an appearance on first load and soon you are in the installer. The OS edition I installed is the “Datacenter edition”. I went with the GUI version, as I decided to check the Core edition out another time. Installation is of course very straight forward not too much has changed since 2008 R2. Within 7 or 8 minutes I was up and running at the logon screen.

 

Installation of Windows Server 8 Datacenter Edition is very straight forward.

 

Windows 8-esq Login Screen

 

Things I like so far are –

  • The new design – clearly all stylised to fit in with the Windows 8 and Windows Phone 7 style etc…
  • New Server Manager – manage multiple servers from one area and create Server Groups.
  • Roles and Features guide seems to give you more detail on some roles (such as Active Directory for example)
  • Task Manager improvements – information is easier to read in my opinion – especially the resources / performance data

 

Annoying things –

  • Server Manager always pops up every time you start up – I’m sure there would be a switch to disable this like Server 2008 though.
  • Start Menu was a little difficult to locate at first! Found it after hunting around a bit though.

 

The new Server Manager

 

Of course I had to jump into PowerShell and check it out quickly- I also used PowerShell to quickly join my Server 8 VM to the lab domain.

Add-Computer -Domain domainname -Credential domainname\adminaccount

 

PowerShell 3.0

 

Task Manager in the Server 8 Beta

 

Well overall my first impressions are it looks good, and seems to run well in VMware Workstation. I’m pretty sure it’ll work fine under vSphere 5 and Fusion too. (Of course probably not officially supported yet as it is Beta etc…) I’m looking forward to exploring the new OS in more detail in the coming weeks.

 

A quick way of finding out where your FSMO roles reside

July 5th, 2011 No comments

 

A nice and simple blog post today, based on finding out where your FSMO roles lie, using just the command prompt. This is useful in a couple of different situations, namely:

 

  • You don’t want to spend a long time using MMCs / Active Directory Users and Computers to figure out where each of the FSMO roles are.
  • You don’t have easy access to MMCs – for example you are using Windows Server 2008 Core

 

This command works on both Windows Server 2003 as well as Server 2008 / R2.

Simply type the following in your command prompt window on one of your domain controllers:
netdom query fsmo

 

Your output should be something like the following, listing the servers which hold each FSMO role.

VMware, Coreinfo and mapping logical CPU cores to physical processors.

June 28th, 2011 8 comments

Sometimes you may have a requirement due to licensing to ensure a Virtual Machine’s CPU configuration is perfectly set out in terms of “physical sockets”. Or perhaps you want to run an operating system such as Windows Server 2003 SE on your Virtual Machine. By default this VM would be limited to only use 4 cores because of the way VMware tells the operating system that each CPU has only 1 core per socket. (Giving it 4 x vCPUs would be the same as giving a physical Windows Server 2003 SE machine 4 x physical CPUs – the actual CPU limit). Either way, it can be quite useful to verify you have the correct CPU configuration.

Enter Coreinfo. This is a handy command line utility by Mark Russinovich which allows you to dump the information about your current CPU and cache configuration for Windows. Download the utility and execute the following command to gather information about the logical CPU core mapping to physical processor.

coreinfo.exe -c -s

In the case of a single socket, six core CPU (such as the one I have running here) this is the output you will see:

 

The Logical to Physical Processor Map information in the first section marks each CPU core with an asterisk (*). The next section, lists the Logical Processor to Socket mappings, indicating how many “processor sockets” your machine has and at which location each Processor Core is at (again marked with an asterisk).

 

If you had provisioned a VM with 4 x vCPUs by default, this would show up with 4 x Sockets and 4 x Physical Processors like so:


Besides being a limiting factor for Windows Server 2003 SE VMs when trying to use 8 x vCPUs (you can’t have more than 4 x “physical” CPUs), this may also be a potential issue with a socket licensed edition of SQL server for example, as you would now have 4 x sockets to worry about with your licensing.

 

So here is where VMware’s useful extra configuration parameters come in handy. These are basically bits of extra configuration you can add to your VMs, and are stored in your VM’s .vmx configuration file. By simply editing your VM, you can add a configuration option which specifies how many Cores per Socket there are. To do this using vSphere, power off your VM, then edit it’s settings. Go to the Options tab, then General, then Configuration Paramaters.

 

 

In this case I have a VM with 4 x vCPUs, which shows up by default with 4 x processor sockets. I want this to be 4 x cores with 1 x socket. So now I would click “Add Row” and in the first empty column, enter: cpuid.coresPerSocket and use 4 as the value in the second column. See this screenshot for specifics (and adjust the value used depending on your desired configuration):

 

 

Power up your VM, and run coreinfo again, using

coreinfo.exe -c -s

 

You should now see that VMware is assigning 4 CPU cores per “Physical CPU socket”. In other words, your VM now has 1 x “physical” processor socket, and 4 x cores. Meaning your single processor application socket is now valid on this VM. Here is the result of assigning my VM a value of 4 for “cpuid.coresPerSocket” when it uses 4 x vCPUs in vSphere:

 

 

As you can now see, it has changed from the original configuration where it had 4 x Sockets listed under “Logical Processor to Socket Map” with a “Physical Processor” for each “Socket”, to showing the 4 x “Physical Processors” all on “Socket 0”.

 

If you are using VMware Workstation, this configuration is easy to do – just edit your VM settings, and look for the dropdown menu under the CPU configuration – change this to how many Processors you want and how many Cores per Processor you will use. (See the screenshot below for an example of 2 x Sockets with 2 x cores per socket):

 

 

Well, that is a brief overview of how to look at your Processor configuration (whether you are using a physical machine or a Virtual Machine), and how to change your CPU socket / core configurations using VMware vSphere or Workstation. The two uses I can think of as stated above are for licensing issues, or issues where you are being limited by what your guest OS can handle in terms of physical CPUs. Feel free to chime in, in the comments below if you can think of any other uses this may have, or if spot a mistake anywhere!

Securing your Microsoft Exchange 2010 Server / services with an SSL Certificate

May 11th, 2011 No comments

Exchange 2010 has definitely simplified the process of applying SSL certificates to your mail services such as Outlook Web Access/App and Exchange ActiveSync. No more muddling about with IIS is required and you can do everything via the Exchange Management Console (GUI) too. I’ll also list a cmdlet at the end for generating a CSR if you wish to go the Exchange Management Shell way.

Exchange Management Console steps:

 

  • Open the Management Console and from the summary / home tab click on “Manage databases”. Now on the list in the left of the Management Console, select “Server Configuration”, then in the list of Actions on the right look for “New Exchange Certificate” and select this.

 

 

  • A wizard will popup and you can begin setting up your new Certificate Signing Request (CSR). Fill in a Common / Friendly name for the certificate. I used the same name as would be used for the actual certificate itself so that I can easily identify it.

 


 

  • Continue the wizard. I won’t be using a wildcard certificate so I will leave the “Enable Wildcard Certificate” selection unchecked.

 

 

  • The next section allows you to select the services you want to use with your SSL / describe the Exchange configuration for the CSR that we are going to generate. Expand out the sections and you’ll see that some are pre-populated for you. Check over this information and tick any services that you want to use. I want this SSL certificate for Outlook Web App and Exchange ActiveSync for mobile devices, so I checked the options for “Outlook Web App is on the Internet” and “Exchange Active Sync is enabled”. In each of those cases, I entered the A name record for the services (The external name used to connect to the services) – i.e. mail.shogan.co.uk – this is important and it is what your SSL certificate will be securing, so double check that it is correct.

 

 

  • Continue by entering some administrative / contact details for your company, choosing a location to the save the CSR request file, then finishing the wizard off. Now, go to your SSL provider’s site and purchase a new SSL certificate. I am using a basic SSL123 certificate in this case from Thawte.

 

  • Go through the steps of purchasing the certificate, and you’ll get to a point where they ask you for the CSR – paste the exact text of your CSR generated in Exchange’s Management Console into the CSR text box on the website and get your certificate ordered. When it is approved and emailed back to you, save the .cer certificate file on your Exchange server.

 

  • Go back to the management console, select “Server Configuration”, select the certificate under the “Exchange Certificates” tab and in the Actions view on the side, select “Complete Pending Request”. Browse for the completed SSL certificate your certificate issuer sent you and finish by completing this wizard.

 

 

  • You now just need to highlight the certificate under “Exchange Certificates” once again, and under the “Actions” panel, click “Assign Services to Certificate”. In this wizard, select your relevant Exchange server name, then click next. On the next screen, select “Internet Information Services”, then “Next”. Check the summary page looks correct then finish the wizard.

 

Your SSL certificate should now be configured and ready for use. Browse to the URL of your Outlook Web App service via https. You should find that you don’t get a certificate warning, and clicking the security icon in your web browser to view the site certificate should show that it is valid and providing encryption.

 

Generate a CSR using the Exchange Management Shell.

 

You can also generate a CSR using the cmdlet below. Just substitute the relevant values with your own. Be sure you aren’t putting any incorrect values in when using this though as you don’t have a nice GUI to explain things to you as you do with the Exchange Management Shell.

 

Set-Content -path “C:\mail_shogan_co_uk” -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048 -SubjectName “c=gb, s=London, l=London, o=Shogan.tech, ou=IT, cn=mail.shogan.co.uk”  -PrivateKeyExportable $True)

 

The above cmdlet will save the CSR file to C:\mail_shogan_co_uk. You would then copy and paste the text of that file into your SSL certificate provider’s site as part of your SSL purchase process. The cmdlet uses some values that will need to be unique to your organisation – here are the value explanations of parts of the above cmdlet:

 

c = country code
s = city
l = province/state
o = organisation name
ou = organisational unit
cn = common name the SSL certificate is to be provided for

The cmdlet won’t give you any output if it works correctly, but you’ll be able to see the CSR in the Exchange Management Console if you refresh it at this stage.

That is basically it – the steps above should help you secure some Exchange services such as OWA or ActiveSync with an SSL certificate from a trusted authority.

 

SQL Server 2008 – Change Tracking

March 11th, 2011 No comments

I have recently started studying for some Microsoft SQL Server exams (in particular 70-432). In order to reinforce some of the information, I thought it would be a good idea to blog about some of the features of SQL Server 2008 I learn about. This post will be on the built in mechanism for Change Tracking.

Change tracking is a relatively lightweight functionality that associates a version with each row in a table which has had CHANGE_TRACKING enabled on it.

By using this mechanism, it should be easy to read the version number when data is read from the database, and when it comes to writing data back, this version number can be checked to see if it has changed or not, allowing your application to determine whether it is safe to write data back or not, depending on how you handle the situation.

Once the CHANGE_TRACKING option has been enabled for a database, you can choose which tables in the database change tracking information is kept for.

Two other options can also be used. Namely CHANGE_RETENTION, which allows you to specify how long change tracking information should be captured for, and AUTO_CLEANUP, which allows change tracking information to automatically be cleaned up.

If anyone has any extra information or can clarify any of the above points, then please feel free to add a comment 🙂