The following steps allow you to view the Exchange certificate properties:
1. Open Exchange Management Console ( EMC ).
2. In the console tree, click Server Configuration.
3. Select the server that contains the certificate, and then select the certificate you want to view.
4. From the action pane, click Open.
==> You can view information about the certificate on the General, Details, and Certification Path pages of the Exchange Certificate dialog box.
Monday, 20 April 2015
Friday, 17 April 2015
IT Security: HTTP.sys Remote Code Execution Vulnerability ( CVE-2015-1635 )
A remote code execution vulnerability exists in the HTTP protocol stack (HTTP.sys) that is caused when HTTP.sys improperly parses specially crafted HTTP requests. An attacker who successfully exploited this vulnerability could execute arbitrary code in the context of the System account. To exploit this vulnerability, an attacker would have to send a specially crafted HTTP request to the affected system.
Tuesday, 14 April 2015
Apple: Configure Startup Application in Mac OS X
There are two method to configure the startup application in Mac OS X:
Method 1:
Add the application to the user's "Login Items" (under System Preferences=>Accounts=[user])
Method 2:
Add a launchd agent to the user's ~/Library/LaunchAgents folder
You may create a new launch agent file as follows:
~/Library/LaunchAgents/my.everydaytasks.plist
With contents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>my.everydaytasks</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/EverydayTasks.app/Contents/MacOS/EverydayTasks</string>
</array>
<key>ProcessType</key>
<string>Interactive</string>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<false/>
</dict>
</plist>
Method 1:
Add the application to the user's "Login Items" (under System Preferences=>Accounts=[user])
Method 2:
Add a launchd agent to the user's ~/Library/LaunchAgents folder
You may create a new launch agent file as follows:
~/Library/LaunchAgents/my.everydaytasks.plist
With contents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>my.everydaytasks</string>
<key>ProgramArguments</key>
<array>
<string>/Applications/EverydayTasks.app/Contents/MacOS/EverydayTasks</string>
</array>
<key>ProcessType</key>
<string>Interactive</string>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<false/>
</dict>
</plist>
VMware: Independent Non-Persistent Mode Not Functioning
For non-persistent mode, the changes are discarded only if you power off the VM (or shutdown the VM). Rebooting VM or reseting VM is different from power OFF and shutdown.
Try to power OFF or shut down the VM for the non-persistent mode to take effect.
Try to power OFF or shut down the VM for the non-persistent mode to take effect.
Apple: Preference / PLIST Files Modification Issue
Something many people do, myself included, is copy an application’s preferences file—either from one Mac to another (as a quick way of getting an app configured to my liking) or to replace a damaged/lost preferences file using a Time Machine backup. Until recently, this process was really simple: quit the app in question, trash the existing prefs file, insert the new prefs file, launch app.
Enter OS X 10.9, aka Mavericks, aka “the easy prefs copy killer.” Apple has made changes to the way the preferences system works in Mavericks, and one casualty of those changes is the easy replacement of an application’s preferences file. A brief bit of before-and-after, and then we’ll get to the fix—or just click the Read More link to jump right to the fix.
In prior versions of OS X, preferences files were always read by the application at launch. So as long as the app wasn’t running, if you replaced its preference file, it would read the new file the next time you launched the program.
In Mavericks, preferences are managed by a background daemon, cfprefsd. This service reads the preferences file once, when you first run the app. It then (I believe) receives notifications if you change the program’s settings while the program is running, and then writes them to the actual preferences file at certain points in time. But cfprefsd always has a copy of those settings in its cache, and that’s what the app gets when it checks its settings. (This reduces hard disk access, which is important in conserving battery life in laptops.)
Here’s the important bit: After you’ve launched an app once, it seems that any subsequent launches also get their preferences from cfprefsd. So if you try the old “replace the prefs while the app isn’t running” trick, you’ll be quite surprised to find that your program launches with its previous settings. It will do this even if you simply delete (via Finder) the old prefs file!
So how do you get around this aggressive caching of preference files?
I’m aware of three solutions, though there may be others (please comment, if you know of a better way).
Method 1:
1. Quit the app
2. Open Terminal
3. Paste killall cfprefsd then press Return. This relaunches the prefs system
4. Now relaunch the app and it should read the modified prefs file
Method 2:
1. Quit the app, and make sure it is not set to run at login
2. Delete the app’s prefs file (typically in ~/Library/Preferences, for non-sandboxed applications)
3. Logout
4. Login
5. Copy the prefs file you want to use into its home
6. Launch the app
Method 3:
1. Quit the app, leaving the ‘bad’ prefs file in place.
2. Open Terminal, paste the following, and press Return: defaults delete 3. com.COMPANY_ID.APP_ID. Note that COMPANY_ID and APP_ID are taken from the name of the app’s preferences file. Using our own Moom for example, the preferences file is named com.manytricks.Moom.plist, so the command would be defaults delete com.manytricks.Moom.
3. Copy the prefs file you want to use into the ~/Library/Preferences folder.
4. Launch the app
Enter OS X 10.9, aka Mavericks, aka “the easy prefs copy killer.” Apple has made changes to the way the preferences system works in Mavericks, and one casualty of those changes is the easy replacement of an application’s preferences file. A brief bit of before-and-after, and then we’ll get to the fix—or just click the Read More link to jump right to the fix.
In prior versions of OS X, preferences files were always read by the application at launch. So as long as the app wasn’t running, if you replaced its preference file, it would read the new file the next time you launched the program.
In Mavericks, preferences are managed by a background daemon, cfprefsd. This service reads the preferences file once, when you first run the app. It then (I believe) receives notifications if you change the program’s settings while the program is running, and then writes them to the actual preferences file at certain points in time. But cfprefsd always has a copy of those settings in its cache, and that’s what the app gets when it checks its settings. (This reduces hard disk access, which is important in conserving battery life in laptops.)
Here’s the important bit: After you’ve launched an app once, it seems that any subsequent launches also get their preferences from cfprefsd. So if you try the old “replace the prefs while the app isn’t running” trick, you’ll be quite surprised to find that your program launches with its previous settings. It will do this even if you simply delete (via Finder) the old prefs file!
So how do you get around this aggressive caching of preference files?
I’m aware of three solutions, though there may be others (please comment, if you know of a better way).
Method 1:
1. Quit the app
2. Open Terminal
3. Paste killall cfprefsd then press Return. This relaunches the prefs system
4. Now relaunch the app and it should read the modified prefs file
Method 2:
1. Quit the app, and make sure it is not set to run at login
2. Delete the app’s prefs file (typically in ~/Library/Preferences, for non-sandboxed applications)
3. Logout
4. Login
5. Copy the prefs file you want to use into its home
6. Launch the app
Method 3:
1. Quit the app, leaving the ‘bad’ prefs file in place.
2. Open Terminal, paste the following, and press Return: defaults delete 3. com.COMPANY_ID.APP_ID. Note that COMPANY_ID and APP_ID are taken from the name of the app’s preferences file. Using our own Moom for example, the preferences file is named com.manytricks.Moom.plist, so the command would be defaults delete com.manytricks.Moom.
3. Copy the prefs file you want to use into the ~/Library/Preferences folder.
4. Launch the app
IT Security: Google and Yahoo Malaysia Hijacked
Google.com.my and Yahoo.com.my is currently down for desktop users after the site was hacked and defaced by unknown culprits. The attack, which happened just about an hour ago, replaced the Google Malaysia and Yahoo Malaysia front pages with a message from the hackers.
The problem was first noticed by users who took to social media to highlight the problem. Google Tweeted that it looks like a DNS redirect. This would mean that Google was not actually hacked, but rather the domain name registry with MYNiC.
It is likely that the problem lies with MYNiC, as the message from the hackers indicates that it was done by the same group who hacked the domain name registrar two years ago. However, the scope of this hack appears to be much smaller, and only affecting the Google Malaysia and Yahoo Malaysia websites.
There are two updates from Google so far:
[Update #1] Google has tweeted that some users are still seeing the problem. We here at Lowyat.NET are also seeing the issue, although some are reporting that it can only be seen when using Google DNS. It also looks like Google Malaysia works properly on mobile devices.
[Update #2] Google has issued an official statement about the incident:
“We’re aware that some users are having trouble connecting to google.com.my, or are being directed to a different website. Google services for the google.com.my domain are not compromised. We’ve reached out to the organization responsible for managing this domain name and hope to have the issue resolved.” It also looks like the Google Malaysia Adwords site was also a victim of the attack. We do not know why this was made a target, but it looks like collateral damage from the hackers.
However, for Yahoo Malaysia, the homepage is currently still down. There is no statement from Yahoo so far.
Friday, 10 April 2015
Microsoft: SQL Performance Benchmark
1. Batch Requests/Sec
Batch Requests/Sec measures the number of batches SQL Server is receiving per second. This counter is a good indicator of how much activity is being processed by your SQL Server box. The higher the number, the more queries are being executed on your box. Like many counters, there is no single number that can be used universally to indicate your machine is too busy. Today’s machines are getting more and more powerful all the time and therefore can process more batch requests per second. You should review this counter over time to determine a baseline number for your environment.
2. SQL Compilations/Sec
The SQL Compilations/Sec measure the number of times SQL Server compiles an execution plan per second. Compiling an execution plan is a resource-intensive operation. Compilations/Sec should be compared with the number of Batch Requests/Sec to get an indication of whether or not complications might be hurting your performance. To do that, divide the number of batch requests by the number of compiles per second to give you a ratio of the number of batches executed per compile. Ideally you want to have one compile per every 10 batch requests.
3. SQL Re-Compilations/Sec
When the execution plan is invalidated due to some significant event, SQL Server will re-compile it. The Re-compilations/Sec counter measures the number of time a re-compile event was triggered per second. Re-compiles, like compiles, are expensive operations so you want to minimize the number of re-compiles. Ideally you want to keep this counter less than 10% of the number of Compilations/Sec.
Batch Requests/Sec measures the number of batches SQL Server is receiving per second. This counter is a good indicator of how much activity is being processed by your SQL Server box. The higher the number, the more queries are being executed on your box. Like many counters, there is no single number that can be used universally to indicate your machine is too busy. Today’s machines are getting more and more powerful all the time and therefore can process more batch requests per second. You should review this counter over time to determine a baseline number for your environment.
2. SQL Compilations/Sec
The SQL Compilations/Sec measure the number of times SQL Server compiles an execution plan per second. Compiling an execution plan is a resource-intensive operation. Compilations/Sec should be compared with the number of Batch Requests/Sec to get an indication of whether or not complications might be hurting your performance. To do that, divide the number of batch requests by the number of compiles per second to give you a ratio of the number of batches executed per compile. Ideally you want to have one compile per every 10 batch requests.
3. SQL Re-Compilations/Sec
When the execution plan is invalidated due to some significant event, SQL Server will re-compile it. The Re-compilations/Sec counter measures the number of time a re-compile event was triggered per second. Re-compiles, like compiles, are expensive operations so you want to minimize the number of re-compiles. Ideally you want to keep this counter less than 10% of the number of Compilations/Sec.
Subscribe to:
Posts (Atom)