All Systems Engineers, Administrators, Security Engineers, Information Security Consultants are worried most of the time on the password policies and the impact that may affect the entire organizations security. And they are absolutely right to worry about this more than anything else as you internals security these days are more worrying factor over the external ones.

You could have the best firewall solutions in place, you may had IPS/IDS, you may had the best NAC/NAP solutions implemented, PKI, encryption, bitlocker … etc. you name it!! Always consider if this any of these walls break, the next step for the attack is to take control over your resources by authenticating, which will require a user and password, once a privileged account’s password compromised, the pain starts.


In this article I will consider talking about field challenges to implement a balanced password policies between Maximum Security, business requirements and the ease of use in acceptable level.


Let us first look at the various attributes of domain password policies as per the best practices:

Attribute Microsoft Default Value Microsoft Recommended Value
Account lockout threshold 0 50
Reset account lockout counter after 0 15 minutes
Account lockout duration Not defined 15 minutes
Minimum password length 0 12 characters
Password must meet complexity requirements Disabled Enabled
Maximum password age 42 days 90 days
Minimum password age 0 1 day
Enforce password history 24 days 24 days


In the above table, these are the settings that you will see in the default domain policy in addition to the recommended values that Microsoft recommends to you to stay secure. The aim of the rough recommended values is to make you secure is in it? Although this remains a challenge to implement such strict recommendation.

All password policy attributes in the above table classified as “Critical” in severity risk classification as each one of these attributes has a vulnerability and countermeasures behind it. Not only that, the value combination plays a role on how each setting will affect other setting as they are fairly and strictly related, all these values in sum will define how far your password policy is security oriented.

To make it easier, I will assume that the readers of this article know what each password attribute means, in case u are not sure please follow this link for description of each attribute:  

Now for each attribute, I will highlight each vulnerability, counter measures and potential impact.

Account lockout threshold

  • Vulnerability: If a bruit force attack targeted a user, this setting will minimize the number of attack attempts where after certain number of failed attempt the account will lock, however, a DoS attack can be performed across the domain by an attacker trying a series of password attacks against all domain users (don’t forget that Active Directory objects are readable by design for all authenticated users!!), if the number of attempts is greater than the lockout value, a Denial of users logon ability will take place.
  • Countermeasures: When the lockout value exists, a vulnerability to DoS may occur as described in the vulnerability. Here are some strong recommendation to overcome this vulnerability at the best:

o   Configure the Account Lockout Threshold setting to 0. This configuration ensures that accounts will not be locked out, and will prevent a DoS attack that intentionally attempts to lock out accounts. This configuration also helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Because it will not prevent a brute force attack, this configuration should only be chosen if both of the following criteria are explicitly met:

1. The password policy requires all users to have complex passwords of 8 or more characters.

2. A strong audit methodology(s) is in place (e.g. SCOM ACS) to alert systems engineers when a failed logons occur in the environment.

o   Configure the Account Lockout Threshold setting to a high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack will still lock the account. A good recommendation for such a configuration is 50 invalid logon attempts, which will prevent accidental account lockouts and reduce the number of help desk calls but will not prevent a DoS attack (as discussed earlier). This option is recommended if your organization does not have complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts.

  • Potential impact: If this policy setting is enabled, a locked-out account will not be usable until it is reset by an administrator or until the account lockout duration expires. This setting will likely generate a number of additional help desk calls. In fact, locked accounts cause the greatest number of calls to the help desk in many organizations. If you enforce this setting an attacker could cause a denial of service condition by deliberately generating failed logons for multiple user, therefore you should also configure the Account Lockout Duration to a relatively low value such as 15 minutes. If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker’s attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.


Reset account lockout counter after

  • Vulnerability: Users can accidentally lock themselves out of their accounts if they mistype their password multiple times. To reduce the chance of such accidental lockouts, the Reset account lockout counter after setting determines the number of minutes that must elapse before the counter that tracks failed logon attempts and triggers lockouts is reset to 0.
  • Countermeasures: Configure the Reset account lockout counter after setting to 15 minutes.
  • Potential impact: If you do not configure this policy setting or if the value is configured to an interval that is too long, a DoS attack could occur. An attacker could maliciously attempt to log on to each user’s account numerous times and lock out their accounts as described in the preceding paragraphs. If you do not configure the Reset account lockout counter after setting, administrators would have to manually unlock all accounts. If you configure this policy setting to a reasonable value the users would be locked out for some period, after which their accounts would unlock automatically. Be sure that you notify users of the values used for this policy setting so that they will wait for the lockout timer to expire before they call the help desk about their inability to log on.


 Account lockout duration

  • Vulnerability: A denial of service (DoS) condition can be created if an attacker abuses the Account lockout threshold and repeatedly attempts to log on with a specific account. Once you configure the Account lockout threshold setting, the account will be locked out after the specified number of failed attempts. If you configure the Account lockout duration setting to 0, then the account will remain locked out until an administrator unlocks it manually.
  • Countermeasures: Configure the Account lockout duration setting to an appropriate value for your environment. To specify that the account will remain locked until an administrator manually unlocks it, configure the value to 0. When the Account lockout duration setting is configured to a non-zero value, automated attempts to guess account passwords must wait for this interval before they resume attempts against a specific account. Using this setting in combination with the Account lockout threshold setting makes automated password guessing attempts more difficult.
  • Potential impact: Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration can increase the number of requests that your organization’s help desk receives to unlock accounts that were locked by mistake.


Minimum password length

  • Vulnerability: Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords.
  • Countermeasures: Configure the Minimum password length setting to a value of 8 or more. If the number of characters is set to 0, no password will be required. In most environments, we recommend an 8-character password because it is long enough to provide adequate security but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the Passwords must meet complexity requirements setting in addition to the Minimum password length setting helps reduce the possibility of a dictionary attack. Note Some regions have legal requirements with respect to password length.
  •  Potential impact: Requirements for extremely long passwords can actually decrease the security of an organization, because users might leave the information in an insecure location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about pass phrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover. Note Older versions of Windows such as Windows 98 and Windows NT® 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems are unable to authenticate with computers or domains that use accounts that require long passwords.


Password must meet complexity requirements

  • Vulnerability: Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.
  • Countermeasures: When combined with a Minimum password length of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it will be difficult (but not impossible) for brute force attack to succeed. (If the Minimum password length setting is increased, the average amount of time necessary for a successful attack also increases).  
  • Potential impact: If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetic characters. However, all users should be able to comply with the complexity requirement with minimal difficulty. If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper row characters. (Upper row characters are those that require you to hold down the SHIFT key and press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments. Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in unhappy users and an extremely busy help desk. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128–0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password).


Maximum password age

  • Vulnerability: The longer a password exists the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the Maximum password age setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.
  • Countermeasures: Configure the Maximum password age setting to a value that is suitable for your organization’s business requirements. When configuring this setting you should also configure the Minimum password age to a value that makes sense in combination with this one.
  • Potential impact: If the Maximum password age setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization, because users might write their passwords in an insecure location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.


Minimum password age

  • Vulnerability: Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords are compromised and if an attacker is targeting a specific individual user account, with foreknowledge of data about that user, reuse of old passwords can cause a security breach. To address password reuse a combination of security settings is required. Using this policy setting with the Enforce password history setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history setting to ensure that users cannot reuse any of their last 12 passwords, they could change their password 13 times in a few minutes and reuse the password they started with, unless you also configure the Minimum password age setting to a number that is greater than 0. You must configure this policy setting to a number that is greater than 0 for the Enforce password history setting to be effective.
  • Countermeasures: Configure the Minimum password age setting to a value of at least 2 days. Users should know about this limitation and contact the help desk if they need to change their password during that 2-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend. When configuring this setting you should also configure the Maximum password age to a value that makes sense in combination with this one.
  • Potential impact: If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user will not be able to change the password until the next day.


 Enforce password history

  • Vulnerability: The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised will remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced. If you specify a low number for this policy setting, users will be able to use the same small number of passwords repeatedly. If you do not also configure the Minimum password age setting, users might repeatedly change their passwords until they can reuse their original password.
  • Countermeasures: Configure the Enforce password history setting to 24, the maximum setting, to help minimize the number of vulnerabilities that are caused by password reuse. For this setting to be effective in your organization, do not allow passwords to be changed immediately when you configure the Minimum password age setting. The Enforce password history value should be set at a level that combines a reasonable maximum password age with a reasonable password change interval requirement for all users in your organization.
  • Potential impact: The major impact of this configuration is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization but make them easier to guess. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords might ask the help desk to reset them frequently.


All the above recommendation are based on studies and analysis of real scenarios where your password policy pain points will suffer from. All the recommendations tackles variety of scenarios where you may consider to maximize the security along with ease of use (in a reasonable way).

Business requirements always play a main role, as security personnel, we always aim to maximize the security practices, this article helps you to guide a well-balanced approach on what could be done to achieve an acceptable level in security and make it aligned with the business needs and requirements.


Putting all together

Based on all of the above, I will give some examples where you can balance, compromise security in some settings where you still cover it in some others, these are just two examples, combinations could go to high number certainly, the examples just to make it easy to compile all the passwords attributes vulnerabilities, countermeasure and potential impact and put them all together in one big understanding vision


Example 1

Attribute Value Why
Account lockout threshold 40 Only if you will disable the complexity and lockouts auditing is enabled
Reset account lockout counter after 15 Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination
Account lockout duration 15 Always same value as Reset account lockout counter after
Minimum password length 8 – 12 When you have Account lockout threshold set to high number, a length of 8 and above will be sufficient
Password must meet complexity requirements Disabled When the Account lockout threshold is more than 40, you can disable
Maximum password age 90 This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend.
Minimum password age 1 1 day is the minimum in any case of attribues value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional
Enforce password history 24 days 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier.


Example 2

Attribute Value Why
Account lockout threshold 0 Only if you will Enable the complexity and minimum password length is 8 or higher, in addition to auditing of wrong passwords attempts usage
Reset account lockout counter after 15 Reduce helpdesk calls and will avoid resetting the counter to Account lockout threshold 0. This setting always recommended to be 15 minutes in any password attributes combination
Account lockout duration 15 Always same value as Reset account lockout counter after
Minimum password length 6 – 8 When you have Account lockout threshold set to 0, a length of 6 to 8 with Password must meet complexity requirements enabled is a must to decrease the possibility of brute force attack surface (not impossible)
Password must meet complexity requirements Enabled When the Minimum password length is equal or higher than 8, this settings is still highly recommended to balance security and make it difficult to brute force attach (not impossible)
Maximum password age 90 This value is important to decrease the password where time frame of attack will be decreased, the lower value, the minimum surface attack will be. 90 days is the maximum value I recommend.
Minimum password age 1 1 day is the minimum in any case of attributes value combination, don’t ever put it 0, as this will make the password history obsolete, increasing it to more than 1 day is recommended optional
Enforce password history 24 days 24 is the recommended in any passwords attributes combinations, and there is no point to decrease it, why would a user re-use an old password again? Re-using passwords will increase the surface attacks for brute attackers where the guessing possibilities are easier.


I hope this article were helpful and informative for you, please feel free to comment, add or ask if you find you may need any help.

Thank you J


Interesting read about OWA in Exchange 2013 where messages get stuck in Drafts folder!

Exchange 2013: Stuck messages in OWA’s Drafts folder and DNS.

Posted: February 21, 2013 in Uncategorized

Let us see how IOS fix will help improve Exchange Experience!!

Thoughtsofanidlemind's Blog

It looks like Apple has released iOS 6.1.2 in an attempt to fix the calendar synchronization problem that causes Exchange servers to log a vastly increased number of database transactions and results in more transaction logs being generated, log replication within Database Availability Groups (DAGs) and potentially service disruption if disks fill up.

This problem has lasted for far too long and it follows on other issues with iOS such as calendar hijacking. In fact, dealing with a calendar seems to pose a technical challenge for Apple, possibly because their experience and focus is centered around the development of consumer applications rather than enterprise-ready software.

I don’t know if the latest fix will work or whether some new bugs are lurking and will be exposed when the fix is applied. No one knows how Apple tests their code against Exchange. If we did, we might have more confidence in the…

View original post 133 more words

The web these days is full with people reporting issues while trying to apply SQL Server related Security updates. A lot of answers is around which are helpful but I couldn’t see any touches the actual issue.
First, when you are trying to apply any security updates, security updates usually requires some per-requisites. So you need to make sure first if you are meeting these pre-requisites like having the latest service pack installed, specific updates or previous security update. To make it easier for you, when a security update released by Microsoft, these is a Security Bulletin associated with these updates, go and read the exact description of the update and the pre-requisites associated with it.

In case you are sure that you are doing everything to the litter according to the book, you will need simply to look at the error code the update produced, common error code related to security updates will be 84B200001 “This error code collected with the KB2716440 security update” so what you will need to do next is to repair your SQL Instances. To update the instances is a simple process, you will need the installation media of SQL Server “Make sure you will use the correct one based on the SQL Server version you have”, to know the SQL Server version you are running, run the following query

Select @@version

For the purpose of the security update KB2716440, make sure your version is 10.50.2500 which indicates SQL Server 2008 R2 SP1

Once you identified the correct installation media you should use, simply follow this article to repair the instances, remember, you should update all instances and on all SQL Server nodes if you are using clustering.
Repair SQL Server 2008 R2 Instance

Basically the instance(s) repair will do the following:

1) All missing or corrupt files are replaced.
2) All missing or corrupt registry keys are replaced.
3) All missing or invalid configuration values are set to default values.

Once you are done. Try to install the SQL Server security update, you should be now rocking easily!!

Hope this read is informative for you, thank you for reading!!

With Windows Server 2008, Microsoft introduced a new concept of applying password policies called “Fine-Grained Password Policy”

As you may know, password policies control on a domain controller will work only with the default domain policy, which made a big restriction on how administrators and security engineers may need to customize the password policies for different purposes on different scopes.

Practically, you cannot assign multiple password policies on different OU within a domain/forest, and still you cannot, the default password policy will always override any other password policy you may try to create in different GPO and different level of linking, no matter what you do, force the policy, block inheritance, even remove the password configuration in the default domain policy or set it to “not configured”, you just cannot. Personally i tried to work around this by writing some complex scripts using VBS before in Windows Server 2003 time, we consulted with experts in AD core, there were simply no solution nor work around, which kept us only praying and hoping for some actions from Microsoft in any SP release or a future release of Windows Server.

Finally, with Windows Server 2008 and later versions introduced, Microsoft offered a way to overcome the limitations i mentioned here previously, by introducing Fine-Grained Password Policies. But let me tell you something, it is not straightforward to do so, you cannot simply create a new GPO and link it to an OU, this still don’t work, you need some special skills to do so, as you will need to deal with AD attributes directly either by PowerShell or using ADSIEDIT. Now i will show you how you can create a fine-grained password policy and what important things you need to be aware of.

Things you need to know before you start:

  • You need to be at least member of Domain Admins group on the specific domain you are going to create the  Fine-Grained Password Policy on. This is the default. Still you can delegate this permission to non-Domain Admins, it is just not recommended to do so.
  • The domain functional level must be Windows 2008 and above.
  • Any Fine-Grained Password Policy will override the default domain policy on the scope that the Fine-Grained Password Policy is applied to. So be careful where and why do you need to apply it.
  • You cannot apply  Fine-Grained Password Policy on OUs. You have to assign it to specific domain user(s) account(s) and/or global security group(s).
  • You will need to view the Password Settings Container under dsa.msc, using Advanced View options to check any custom Fine-Grained Password Policy created and for future modifications.
  • This will work with users logon to any Windows client OS, in XP a warning message may appear to users while trying to change password if the Fine-Grained Password Policy applies to them, you can safely ignore this message.

Creating Fine-Grained Password Policy using two methods

1) Using ADSIEDIT:

  • Click Start, click Run, type adsiedit.msc, and then click OK
  • n the ADSI Edit snap-in, by default you should be connected to the Domain where you run adsiedit.msc, if you need to connect to a different domain, ADSI Edit, and then click Connect to. In Name, type the fully qualified domain name (FQDN) of the domain in which you want to create the PSO, and then click OK.
  • Double-click the domain.
  • Double-click DC=<domain_name>
  • Double-click CN=System
  • Click CN=Password Settings Container
  • Right-click CN=Password Settings Container, click New, and then click Object
  • In the Create Object dialog box, under Select a class, click msDS-PasswordSettings, and then click Next
  • In Value, type the name of the new PSO, and then click Next
  • Now you will need to follow the Wizard, the below table will have the details description of all attributes that required with value examples.
Attribute name Description Acceptable value range Example value
msDS-PasswordSettingsPrecedence Password Settings Precedence Greater than 0 5
msDS-PasswordReversibleEncryptionEnabled Password reversible encryption status for user accounts FALSE / TRUE (Recommended: FALSE) FALSE
msDS-PasswordHistoryLength Password History Length for user accounts 0 through 1024 3
msDS-PasswordComplexityEnabled Password complexity status for user accounts FALSE / TRUE (Recommended: TRUE) TRUE
msDS-MinimumPasswordLength Minimum Password Length for user accounts 0 through 255 6
msDS-MinimumPasswordAge Minimum Password Age for user accounts
  • (None)
  • 00:00:00:00 through msDS-MaximumPasswordAgevalue
2:00:00:00 (2 day)
msDS-MaximumPasswordAge Maximum Password Age for user accounts
  • (Never)To set the time to (never), set the value to -9223372036854775808.
  • msDS-MinimumPasswordAgevalue through (Never)
  • msDS-MaximumPasswordAgecannot be set to zero
60:00:00:00 (60 days)
msDS-LockoutThreshold Lockout threshold for lockout of user accounts 0 through 65535 10
msDS-LockoutObservationWindow Observation Window for lockout of user accounts
  • (None)
  • 00:00:00:01 through msDS-LockoutDuration value
0:00:15:00 (15 minutes)
msDS-LockoutDuration Lockout duration for locked out user accounts
  • (None)
  • (Never)
  • msDS-LockoutObservationWindowvalue through (Never)
0:00:10:00 (10 minutes)
msDS-PSOAppliesTo Links to objects that this password settings object applies to (forward link) 0 or more DNs of users or global security groups “CN=xyz,CN=Users,DC=DomainController,DC=yourdomain,DC=extension”
  • On the last screen of the wizard, click More Attributes
  • On the Select which property to view menu, click Optional
  • In the Select a property to view drop-down list, select msDS-PSOAppliesTo
  • In Edit Attribute, add the distinguished names of users or global security groups that the PSO is to be applied to, and then click Add
  • Repeat the previous step if you need to add more users/security groups
  • Click Finish

2) Using PowerShell:

The below is a sample of a PowerShell Code, you can simple copy and paste it, and change the values of the attributes as suites you:

New-ADFineGrainedPasswordPolicy -Name “FineGrainesPassPolicy” -Precedence 20 -ComplexityEnabled $true -Description “Special Domain Users Password Policy”-DisplayName “Domain Users PSO” -LockoutDuration “0.10:00:00” -LockoutObservationWindow “0.00:15:00” -LockoutThreshold 10 -MaxPasswordAge “60.00:00:00” -MinPasswordAge “1.00:00:00” -MinPasswordLength 7 -PasswordHistoryCount 5 -ReversibleEncryptionEnabled $false

After that, you need to go the Password Settings Container under system container. “As mentioned you will need to enable advanced view options to see this container”, then locate the just created PSO “Domain Users PSO” then you need to go the properties, and edit attributes tab, locate msDS-PSOAppliesTo attribute, then add the users/security groups you need this PSO to apply to.

The above two methods is your easy way to apply this nice concept, that you may want to apply it in case you have specific extra security requirements in mind, this will be your easiest and best way to do so.

Real-Life issue: Some Engineers reports that the Fine-Grained password policies will not apply to certain users are members of security group, the reason is your group is not a Global Security Group, so make sure that the groups are Security Groups, in addition they are only Global Security Groups. This will not work with Distribution Groups as they don’s have SID and won’t work with Universal nor Domain Local as their nesting hierarchy will involve complex groups memberships for groups in different forests.

I hope this is a good informative reading for you, in case you have any questions please leave them down below in the comments and will be glad assist 🙂



When Microsoft announced Windows 8 with their beta version lineup starting from beta, developers preview and consumers preview, I had a lot of comments and points against the new path Microsoft took toward developing this new OS.

The way Windows 8 experience was almost totally different from what we used to deal with in previous versions was a dramatic change, somehow radical in another word.
If you look practically at Windows 8, it is just a great continue of Windows 7 success, sharing most of the kernel characteristics of MinWin from Windows 7, Microsoft managed to put a new layer over a Windows 7 based interface, they called it Metro UI at the beginning.

Looking deeply into this UI, it is fashionable, fancy and nice looking one, especially when it comes to the feel and general look, it is just what we thought we need to see in future Windows release.
I have no doubt the interface is a revolutionary step for future releases, but for the time being, I just see it doesn’t work as intended to be, at least this is what I think!!

Coming down to the practicality of use, the new UI is not easy to use for the first time and even after few days of discovery journey. The way you may interact with the UI at some points is nice and easy, some other parts is just not practical and with no use, you will feel like you need to have extra efforts to get simple things done. E.g. When you need to search for a file, you need to navigate with your mouse to the top-right corner, click the search icon, so far nothing wrong right? This is an extra one step you need to take in comparison to Windows 7, but this is not it, now lets say you want to type a file name, simply you will never find it!!! Because you are searching in the apps by default. Microsoft categorise the search results into categories like apps, files, setting … Etc. so if you are not looking for an app by default, u will need to have another click on the category you are looking for. This is just NOT right!!

Another downside is the applications, you feel practically you have two different types of apps, the apps we used to find in Windows 7 and the apps comes within the store in Windows 8, you just cannot feel that the applications are desktop applications, actually they will never run in a desktop mode, you will need to live and manage them within the Metro UI, but apps like like Office will run in the desktop mode, this is really confusing. This even applies to the stock apps like IE 10, why do we have two browsers?!! Yes 2 IE 10, the IE you will run in the Metro UI is not the same IE you will run in the desktop mode!! So if you are opening many apps varies between desktop and metro, you will simply get lost, I don’t feel the same consistency we used to have in Windows 7 anymore, you will have the fell you are running two different OS on the same screen!!

Metro UI built with great focus on touch, it meant for tablets and touch screens all-in-one systems, because simply what you can do with the touch gestures cannot be done with a mouse and keyboard. So here Microsoft lost the consistency, they focused on one direction and forgot why Windows OS has been built!! It is a desktop OS!! It meant to be great for both work and home/entertainment use.

I need to jump into the core of this article, which is the business use, they above paragraphs are an introduction on how Windows 8 can be confusing for average consumers and you can find tons of articles and blogs just talking about that, my aim here is to evaluate it from business perspective.

Windows 8 is a none-business oriented OS at all, here are my reasons.

– Practicality: It is just a nightmare, I even have one of my colleagues told me “I felt I am a handicap!!” Which is somehow true. As an IT Pro. or a business oriented user, you will spend your time on the desktop only, but the metro UI will force you to use it when you need to search for a file or an application, and for the reasons I mentioned above, it is just impractical, everything you used to do in Windows 7, you will need extra steps to achieve it in Windows 8. Why do I need to have three click to go to control panel? Why do I need to care about the search terms and where I need to search? I just want to search.

– Support and Engineering: Well, I will not talk about the architecture here because nothing is wrong here I think, I will talk about drivers support and desktop applications compatibility, now as I mentioned, as long as Windows 8 shares the same kernel of Windows 7, why do we have application and drivers incompatibility? And the problem is, some of these applications are Microsoft based solutions, for example, I cannot. Control nor do anything to manage Windows 8 clients using System Center Configuration Manager (SCCM), you will push the SCCM agent and it will install, nice, this is the maximum you can reach!! You cannot push Forefront Enterprise Protection security agent, it is just incompatible, you cannot push Windows updates, you cannot read the system resources, you cannot generate any report on any client whatsoever!! Live with it till you upgrade your SCCM 2007 to 2012, even you have 2012 now, your will wait till they release the Service Pack 1 (SP1), till that time you are in a dead zone.
Drivers: for the first time you will feel Windows Update will take care of your drivers installation, and you will be happy!! Over time you will notice you have lag in the overall performance (this will vary based on the hardware model). I faced this issue with a lot of users, after deep investigation, I found that most of the drivers are not Windows 8 specific, they a re just Windows 7 Drivers optimised with backward comparability, so drivers will install, but they are not practically optimised or meant to be for Windows 8, you will face this the most with BIOS drivers, network drivers and graphics drivers, they looks like working, and they do, but not at the best (Damn!! That reminds me of Windows Vista 😦 ).

If you have group policies to control your clients through Active Directory, some basic ones won’t work like default website in IE and most of IE setting, custom login scripts built using VBS, even some basics like screen saver and screen timeout.

I think Microsoft need to look apple model, Mac OS X and IOS, they are two different categories, still they are very well integrated, each built for their own use, IOS is a touch oriented OS with ease of use and balanced, yet the Mac OS X with the variety of gestures using their trackpad is great and it is the right alternative way to achieve a touch-like behaviour, but it never meant to be touch!! Which is really great. They guarantee a user understanding continuity for what they have to do when they have a IOS powered device and a Mac OS X powered machine!! Great job Apple, this is a statement from Microsoft IT Pros.

The button line, Windows 8 is not business ready OS. I wonder how Microsoft released it with this big gap to make other enterprise products Windows 8 ready!!

Memory flashback: Between Windows releases, look at Windows 98, it was great, Windows Me was a failure, Windows XP was great, Windows Vista was a disaster!! Windows 7 was a big hit, now Windows 8!! So as you may noticed, between Windows releases, there is 1 in the middle which is a failure!! I guess Windows 8 isn’t that great release, I am expecting a new release in 2 years time.

PS: I am going back to Windows 7 on my work (Workstation laptop) and keeping it on my home laptop. Why? Testing and intensive reviews are always important for me as an IT Pro. Even it sucks I have to live with it so I won’t miss a thing 🙂

Nokia Lumia 920 heating issue explained!

Posted: December 16, 2012 in Phones

Nokia Lumia 920 is definitely one of the most powerful, solid and sexy looking Windows Phone 8 powered devices, since the device released, contradictory feedback was given from various users indicating how much happy they are or how mad they are with device.

After the random reboot behaviour issue that all branded Windows Phone 8 powered devices suffered from including HTC and Nokia, which has been confirmed and admitted by Microsoft, they promised a fix to this issue, an OTA already pushed to HTC 8X, leaving Lumia 920 the only leading device waiting for this treat.

Is that all? Nope, there is a new player of the drops issues (Hope drops will not count to reach an ocean!!). Nokia Lumia 920 users are reporting an overheat issue on the top back of the phone in addition to deterioration in battery life, which makes users scared and annoyed. On forums and discussion boards there are lots of defenders and attackers, some users tried hard to help by suggesting different tweaks, starting from disabling NFC, GPS, background apps …. etc. Nothing helped.

Users claim it on the apps running in the background, which certainly could be a reason!! what? a  few maximum apps in the background could make the phone suffers from an overheat issue? Android with their theoretically infinity multitasking apps never ever suffers from this issue. Some users confirmed the issue happened even when NULL is running in the background, and the NFC … etc. tweaks applied.

From all the above, i decided to do my own test and investigation on my Lumia 920 unit, here what i found:

1) Built in applications running in the background will never cause the phone going warm, only after heavy use of Nokia Drive, City Lens and Camera, you can feel slight warm in the back top of the device, still this is not an over heat and normal this happen due to processor clocks to a full speed for consistent amount of time, this is reasonable, iPhone and Android power devices could get warm from similar activities.

2) Testing third party apps, even there is no huge selection of applications that are commonly used, but after careful asking users who faced this issue, i found that social networking apps are the most common apps installed of the complaint users. Facebook, the application certainly buggy and lacks proper notification, through out testing the app still function properly in coordination with WP8 OS, i didn’t notice any issue of battery drain nor overheating stuff, same applies to a lot of other applications like twitter, tweet caster, youtube, camera lenses apps … etc. Finally i came over the real play maker!! WhatsApp!! W T ….

Yes, the whole issue with WhatsApp, after using it for few texts, i notices noticeable heat increase in the top back, and things are under fire as more as i am using the app, i felt like am doing my fingers BBQ treat while holding the phone using WhatsApp, in addition, battery drain!! OMG, that was the fastest battery drain test i ever ran over in my lifetime using gadgets.

To conclude what happened with simple technical language with less fat. WhatsApp is malfunctioning in the background, took advantage over the S4 Processor, reserve all cores and threads to the application and over-clocking the CPU intensively. Even when you close the app, practically you are not, the App will keep going for some time in the background (15 to 20 minutes) abusing the devise resources without even functioning the application, that being said, the app will only release the devise resources when it goes idle which is not a fixed duration based on my intensive test. The app will dramatically drain your battery for granted, and will make you have a hot chill fried fingers after few minutes of using it. When i uninstalled the app. Yeaah fixed right?? Nope!! Why, the app looks sticky to some DLL libraries which calls the CPU registers (If you know assembly language and microprocessors you can tell!!), making these DLLs corrupted, and your only cure will be to factory reset your phone or giving it back to warranty to push a fresh OS copy.

Update: WhatsApp pulled out the application for the Market few days back, yesterday they published with new version number 2.8.1 which is obviously a proper one (so far as my test goes).


I hope the above will put an end to this myth, i wish you find it informative, see you in the next drop!!