@ammarhasayen

Main menu

Tag Archives: Windows

Post navigation

If you are responsible of writing SharePoint workflows using the SharePoint designer, I want to share with you a small tip when it comes to using the SharePoint designer console.

Usually, you have SharePoint servers and perhaps Workflow Manager in your data center, and you may have installed the SharePoint designer at your machine and connect remotely in order to start coding workflows.

What I do not like in this case is the dependency on the link. Sometimes you work remotely from a hotel room connecting to unreliable wireless network, connecting VPN to your corporate network, opening the SharePoint designer console from your machine and opening a very big workflow definition code, do some modifications and hitting Publish. You do not know what will happen if the network connectivity is not reliable.

What I prefer is to have a Remote Desktop server in the data center to do administrative tasks for different thing. You can then install the SharePoint designer in that remote desktop server, and then you can log remotely to that server and open the SharePoint designer from there. That way, when you hit Publish workflow, the changes will be pushed from the terminal server to that SharePoint farm without depending on any unreliable connection. Furthermore, I also have exported the SharePoint designer as a remote web app and copy it to my desktop. Whenever I want to use the designer, I just open the RDP file in my machine, which will connect using RDP to the RDS server in the data-center and give me a great experience.

Even if you connect from your hotel room, connecing via unreliable wireless network via VPN to your corporate network, you will RDP to that RDS server, use the SharePoint designer from there, open your big workflow code, do your changes, hitting Publish, and you do not worry about anything. In fact, you can close your VPN connection and the background, the SharePoint designer will take its time publishing your workflow changes without any networking issues.

Like this:

I spent long time helping in deploying Windows 8 in big enterprises by testing the new O.S when it first shipped, and validating application compatibility. I have played with the original Windows 8 and Windows 8.1 ISO files in many ways. I used WDS to deliver the image [Check this post], and i even created a custom image pre-loaded with corporate software [Check this post].

I thought everything is cool, until we started to hear some feedback about slowness. Across 2000 Windows 8/8.1 sample machines, the feedback about slowness was so strong that we could not ignore anymore. We identified the problem as per the following:

” When booting a Windows 8 or Windows 8.1 machine, and after entering the credentials to log on, the desktop freezes for about 3 minutes before everything suddenly start to respond. High disk profile is noticed from while to while also. This only happens after joining the machine to the domain“

Investigation

We started to suspect that our custom Windows image is causing the slowness, so we started to redeploy Windows using the original ISO without any modification. This did not help.

We started to suspect the big number of group policies that the corporate has. The AD team started to consolidate group policies so that instead of applying corporate settings in the form of 25 group policies, now they reduced it to 8 policies. This did not help also.

Logs are clean, nothing is crashing. We suspected that the AntiViurs is causing such slowness, or even the data loss prevention solution deployed to workstations. Another dead end. Problem did not go away.

One interested fact is that this slowness happens after joining the machine to the domain. We did the following to understand why joining the machine to the domain causes this slowness:

– Create an OU in AD called “Investigating Slowness”

– Apply Block Inheritance on that OU, to prevent any group policies to be applied on machines under that OU.

-We created a computer account called (Machine1) under that OU, then we formatted a new machine with the same name, and we joined it to the domain.

– We confirmed that slowness is not happening so far even after joining the machine to the domain. So we suspected a group policy setting.

– We started to link one group policy at a time to the “Investigating Slowness” OU, and reboot the machine each time and monitor if slowness is happening.

– Finally we found the cause of the problem !

Solution

The reason behind the slowness is simply the BranchCache policy that is applied via group policy. The policy configures the BranchCache to be set to Automatic and it configures Distributed Cache mode.

I read about enhancement in BranchCache for Windows 8 and Windows 8.1, and it was a big shock for me to know that the reason of such slowness was caused by BranchCache in Distributed mode.

Anyway, after removing that group policy, machines are operating faster, and they are not freezing after booting and signing in.

Like this:

I was trying to add Windows 8.1 Key to Active Directory that day using Volume Activation Management Tool (VAMT) to enable AD based activation, and i get the “Invalid product key or license mismatch”error when trying to add the Windows 8.1 KMS key using AD based activation.

Doing a quick search, i found this hot fix from Microsoft http://support.microsoft.com/kb/2885698/en-us under the title of (Update adds support for Windows 8.1 and Windows Server 2012 R2 clients to Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 KMS hosts). Installing the fix on the server where VAMT is installed solves the issue and saves the day!

Share this:

Like this:

I’m writing this paper to show the big difference Microsoft Windows Vista is introducing in the boot process. In order for system administrators to support and maintain windows Vista, they should know a little about the boot process in order to be able to troubleshoot startup problems and possibly multi-operating system in the same box. This writing will show only headlines about this subject but it will definitely help you in being familiar with the boot process and the new standards Vista code is utilizing.

When you first boot you machine (turn it on), the machine’s BIOS will load to memory and perform some hardware checks and then will start searching for connected disks or media (i.e. you configure the BIOS to boot from bootable CD first).

If the Boot order in the BIOS is configured to boot first from disks, then a boot disk is chosen and the Master Boot Record “MBR” on the system (Active) partition is loaded.MBR then will continue from here to located operating systems and optionally displaying boot menu to the interactive user.

This was the case for long time and this sequence of boot process is known as PC BIOS standard boot sequence.

So, things are good so far, you turn on your machine and believe it or not, it really boots! So what’s new?

During the development of the first Intel-HP Itanuim system in mid 1990s .PC BIOS limitations were sees as clearly unacceptable for the large server platforms Itanuim was targeting. The initial effort to address these concerns was initially called Intel Boot Initiative and was later renamed to EFI (extensible Firmware Interface).

So now we have this new EFS Specification. The rest is boring, as EFS specification 1.02 was released by Intel on December 2000 and then released in mid 2002 as EFI 1.10.Now EFI Forum is responsible of this standard and the standard is sometimes named Unified EFI.

In summary, we have the old PC BIOS method or booting and now we have the new EFI method of booting which is more advance and allows for more flexibility. Believe it or not, Vista now supports this new EFI Specifications.

PC BIOS Boot method in Vista

First, when the computer is switched on, BIOS is loaded. Then the MBR of the boot disk, which can be a hard drive or external media, is accessed, followed by the boot sector of the drive or of relevant hard disk partition. For Windows Vista, the boot sector loads the Windows Boot Manager (Filename: Bootmgr.) which accesses the Boot Configuration Data store and uses the information to load the final stage, the Operating System.

So first step in the booting process is the BIOS which discover all connected media and disks and chooses the appreciate boot media or disk according to the boot order configuration configured on the BIOS. If the boot process is to start from a disk media, then it is the function of BIOS to search for bootable H.D .Once found , BIOS will handle the boot process to the H.D MBR.

Master Boot Record MBR

Think of this half KB of data as the person who knows everything about the H.D and uses this information to handle the boot process. The MBR maintain a table that contains the partitions existing in this disk .In MBR maintains the Disk Signature.

Disk Signatures are a way for operating systems to differentiate different disks in case of RADI configuration for example. When you connect a secondary H.D to your machine, the windows will detect a new HD and will ask you to initialize this new H.D Initializing H.D involves stamping the H.D with a unique Signature.

As mentioned before, MBR contains Partition table (can have maximum of four entries, thus you can have maximum of four primary partitions, although you can configure the last primary partition as extended partition to hold embedded logical partitions).MBR then will look for the partition that is flagged as Active (system partition).

Windows Boot Manager and BCD

Once the Active Partition is located, the MBR invokes the Partition Boot Record (PBR) which then looks for Windows Boot Manager which then queries the Boot Configuration Data BCD. In Windows Vista, Windows Boot Manager and Boot configuration data are replacement of NTLDR.

So MBR looks for active partition and kicks of the Windows Boot Manager which stores information in something called BCD.

Boot Manager reads configuration from BCD and displays the boot menu to the user. Boot Configuration Data is a replacement of boot.ini and is stored on \boot\bcd on the system partition.

Boot Configuration Data contain the menu entries that are presented by the Windows Boot Manager, just as boot.ini contained the menu entries that were presented by NTLDR. These menu entries can include:

·Options to boot Windows Vista by invoking winload.exe.

·Options to resume Windows Vista from hibernation by invoking winresume.exe.

Boot Configuration Data allows for third party integration so anyone can implement tools like diagnostics or recovery options.

WINLOAD.EXE

winload.exe is the operating system boot loader. It is invoked by the Windows Boot Manager in order to load the operating system kernel (ntoskrnl.exe) and (boot-class) device drivers, and is in that respect functionally equivalent to (the operating system loader functionality of) NTLDR in prior versions of Windows NT.

Disk Signature

It is very interesting the way Vista boot process handles the digital signatures of the H.Ds connected to the box. In previous NT operating systems the integrity of the disk signature was in most situations not crucial for ntldr to initiate the Windows boot process.

With Vista on the other hand, if the signature has changed or can’t be found then the successor of ntldr, bootmgr, will halt before Windows is started with the error winload.exe….. is missing or corrupt. It is an inaccurate and misleading error message because winload.exe itself has not actually moved or changed. If I alter one digit of the signature then it’s a winload.exe error, if I change it back again then Vista boots as before.

Both ntldr and bootmgr have to first identify which hard drive they should look on. The ntldr does this with the aid of the boot.ini file, which lists the hard drives by number in the same order as the computer’s BIOS sees them. The ntldr consults the boot.ini for the number of the drive that it wants and then checks the BIOS to find the location of that drive. In Vista the BCD store does not list hard drives by number at all but rather by their unique disk signature. When bootmgr queries the BCD for the drive it wants it is told the disk signature of that drive, so it then scans the connected drives till it finds the one with that signature. If no match is found then bootmgr cannot continue to look for the Vista bootloader (winload.exe) and hence displays the error message that winload.exe……is missing or corrupt.

Note 1: Only nonversion-specific components are stored in the root of the active partition. This means that theoretically Windows Vista could be installed on a machine running some future Windows version with the same boot structure, and it would not break the boot process for that future version. With legacy Windows, installing an older Windows version last causes the newer version to fail on start-up. This is due to version-specific code improvements in Ntldr.

VISTA MBR Integrity

On systems that have BIOS firmware, Windows Vista and earlier versions of the Microsoft Windows® operating system install an MBR during setup of the operating system. For earlier versions of Windows, some system manufacturers provide additional tools and experiences by installing an OEM-specific MBR to “hook” the boot process. For example, an OEM-specific MBR might jump to an OEM-specific hidden partition that contains the manufacturer’s boot applications when the user presses a particular key during the BIOS phase of boot.

Microsoft recommends not replacing the MBR with any hardware specific one. BitLoacker for example uses some integrity check to validate the MBR hash values to make sure it is not changed from last reboot. Windows recovery tools can repair a H.D by replacing the MBR with a new one. To solve those issues, Vista supports the ability to define actions to perform in response to keyboard scan that is received during reboot.