Windows 7 – Cool Features – 002

After talking about Problem Steps Recorder Tool (Frontslash – Windows 7 – Problem Steps Recorder Tool), here’s another cool feature that Windows 7 brings to corporate environments.

It’s called Branch Cache, and in simple words, what it does is cache files that an user access in the branch, so that when another user asks for the same file, the access time will be quickier.

This feature will also be available in Windows Server 2008 R2.

You can see a interview with Devrim Iyigun from Microsoft, on the Technet website, where she explains more deeply this new feature:
Technet – Branch Cache in Windows 7

Windows 7 – Problem Steps Recorder Tool

Sometimes, little tools mark a big difference.

One of that examples its a new very helpful tool that cames with the beta version of Windows 7.
It’s simply called Problem Steps Recorder Tool (PSR) and does exactly what it says.

This nice idea can make the support’s teams life easier. Sometimes the users can’t make their point and have some difficulty to explain wha’t happening.What this tool does is to record every step the user make from the time he clicks the “Start Record” button. Then, this advanced screen capture software, takes something like “Print Screens”, of mouse clicks, key strokes, and get some technical info too.

After the recording the user gets a zip file containing all the information and can send it too the support teams.

You can get more information and a demonstration video of this tool, from the Microsoft Technet website:
Microsoft Technet: Problem Steps Recorder

Nice, really nice work.

Microsoft Windows 7 – The First Contact

Last Friday I had my first, very superficial, contact with Windows 7 Beta 1.

Although this is an early form of the new OS from the Redmond company, I need to admit that it was very impressive.
Very very fluid, in a very low spec notebook.

This beta was shown to me through a Microsoft worker so when I told him that now I was pretty sure that Windows Vista was the new “Millenium” he just smiled to me…

For all of you that want to download the Beta 1, here’s the link:

MS Windows 7 Beta 1 Download

KMS – Activating Windows on Isolated Networks / Standalone Computers

In some particular cases you may not have the possibility to active Windows through the normal KMS process, because you have some machines that for example:
- Aren’t joined to a domain
- Don’t have DNS configured

But of couse, you still need to activate Windows on this machines. On more “complicated” way is using something, that I’ve not tested, called VAMT that make it possivel to run a tool on the isolated machine and than send the generated information through another machine. This is obviously causes more effort for the activation and on unattended deployment scenarios (LTI or ZTI) it’s not very convencional.

This week someone from the middleware team, finally installed KMS Server on the network and finally I could test this scenario because we have some kiosk type machine that need this kind of solution.

Windows Vista clients uses DNS queries to find where KMS Server is located, and in my scenario I couldn’t have DNS configured on the machine, so the challenge was, some how, to force the client to know where the server was.

So…after some search and a very very nice help from a Microsoft fellow (Nino Torres) we found a way to do this.
There’s a tool called slmgr located on ‘C:\Windows\System32′ that can be used to force Windows to know where the KMS Server is giving it the ipaddress and listening port.

On unattended scenarios you should use the vbscript (also located on ‘C:\Windows\System32) called slmgr.vbs.
To force the KMS Server information, you should run the following commands:

- cscript C:\Windows\System32\slmgr.vbs -skms kms_server_ip_address:portnumber
- cscript C:\Windows\System32\slmgr.vbs -ato

Example:
cscript C:\Windows\System32\slmgr.vbs -skms 10.0.0.1:1688
cscript C:\Windows\System32\slmgr.vbs -ato

The first line, sets in registry the information about the KMS Server IP Addres and the port his listening to.
The second line, forces the Windows Activation.

[CAUTIONS]
:: In most cases, isolated networks have firewall, so we need to open the way for KMS Server.
:: The default port for KMS Server is 1688
:: Don’t use slmgr for unattended installions because it shows message boxes, use slmgr.vbs instead

For more information about Volume Activation visit this Microsoft Website:
Volume Activation 2.0 Technical Guidance

Installing .NET Framework 3.5 SP1 Causes Windows Setup Error

For having my images up-to-date I started this week testing the deployment for .NET Framework 3.5 SP1.
At first everything looks ok, and the software installs silenty.

The problem was then deploying the image. For some reason during the setup I was getting this error message:

NETFramwork3_5_SP1_Error_001

Because I’ve made some other changes to the proccess I needed to have sure that .NET Framework 3.5 SP1 was the problem here, so I’ve disable this step on the Task Sequence and then created a new image again.
Now the problem didn’t happen.
h
After some research, asking people about it I’ve run out of options so I’ve installed .NET manually to see if I could understand where the problem was.
After installing I’ve reboot the system and then realized that after restart the .NET installation need to update something on the system (similar to the process after installing some hotfixes via Windows Update).

I’ve then enabled the .NET installation step again and add a Restart Computer step to my Task Sequence. Before this the space between installing .NET and Sysprep the machine had no reboot.

Create the image and now everything works correctly.