When you try and install the MSI package created by app-v sequencer or launches the application on a standalone app-v client it fails to initiate.
With error: 4505CD-14901C04-0000180B
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cause
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\Configuration\AllowIndependentFileStreaming is set to 0.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Resolution
we need to change it to 1.
and it works fine
Disclaimer: "The information provided here is AS IS"
All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
Hi all, I am a support engineer working in Setup\Cluster team at Microsoft and I am going to share some views on failover clustering feature via this blog. There is couple of new features and architectural changes in failover clustering 2008 R2 and I am going to talk about it in this blog.
One of the major changes which clustering team came up with is live migration and cluster shared volumes features. Now if you create a hyper-V cluster and create highly available virtual machines on it, these highly available virtual machines can be moved from one node to another while they are online without any downtime. This magic is achieved by the new cluster shared volumes feature described in detail here . You can enable CSV feature in failover cluster console to take benefit of it and do live migration without any downtime. (See fig 1). This feature is only supported for Live migration of highly available virtual machines as of now as seen in disclaimer below in fig 1. You can enable and deploy Cluster shared volumes and live migrate your highly available VM’s as explained here .


Fig 1
Another major change is introduction of Power shell for managing failover clusters. Power shell will ultimately replace cluster.exe however it is still there in 2008 R2 and will be removed in next server release. This blog post will provide an overview of Power shell with Failover Clustering. (See fig 2)

Fig 2
In 2008 R2 failover clustering you can do much more from within the failover cluster console. You can completely manage your virtual machine from failover cluster console now like connecting to virtual machine, modifying the settings for virtual machine, turn off, shutdown and save state along with live migration and quick migration. (See fig 3)

Fig 3
We know that if a network does not have default gateway, the network is configured by default as private network. A major change that we have done is provided metrics to the networks. Private networks metric starts with 1000 and public networks metric starts with 10000. If you have multiple private networks their metric will increase by 100 and 1000 for public networks. You can see in fig 4 that my CSV network is highest priority private network (metric: 1000, lowest metric) and then my LM network is the second highest (metric: 1100, second lowest metric) private network. You can also see the metric for my priv pub network which is my default public network is 10000.
You can now set network priorities the way you want instead of letting cluster manage it automatically for a virtual machine and you can have different network priorities for different virtual machine. (See fig 4).By default cluster will use 1100 (network with second lowest metric) metric network for live migration which in my case is LM network. We don’t obviously want our CSV traffic and LM traffic going on same network. So automatically my 1000 metric network goes as the last priority (see fig 4)
Yes you can modify these metrics if you want to do that manually.


Fig 4
There are some nice features like heartbeat monitoring for the virtual machine (see fig 5)

Fig 5
You can now also restrict an administrator from making any changes in the failover cluster console by providing him read-only access. This can be done via power shell (see fig 6). Last but not the least we have also modified tracing for failover cluster and it is better than what it was in server 2008.

Fig 6
I hope you enjoyed reading this and these are just the main new features and architectural changes but not all. Please come back on our team blog where we try to share information with our customers and Thanks for your valuable time.
Gaurav Anand
Support Engineer
Microsoft EMEA Setup\Cluster team
Disclaimer: "The information provided here is AS IS"
All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
We should initially approach to uninstall WSUS 3.0 gracefully, but if it fails by any chance, we can follow the below mentioned steps to remove it manually. It will uninstall the WSUS completely.
1. Download the SDK to obtain MSIZAP.exe file.
2. From a command prompt, type:
For WSUS 3.0: MSIZAP T {77846B52-14C9-4fc4-BE63-FE06AF501442}
Note: If you also want to remove the old Windows Internal Database from the computer, you must use the msiexec.exe command to remove Windows Internal Database.
msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} CALLERID=ocsetup.exe
Delete HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\Windows Internal Database (if available)
Delete HKLM\System\CCS\Services\MSSQL$MICROSOFT##SSEE (if available)
Delete HKLM\Software\Microsoft\Microsoft SQL Server\MICROSOFT##SSEE (if available)
Delete %windir%\SYSMSI folder (if available)
3. From a command prompt run the following commands to delete WSUSService and WsusCertServer
sc delete wsusservice
sc delete wsuscertserver
4. Delete the following registry entries (if available)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSUS: Client Web Service Methods
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSUS: Reporting Web Service
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSUS: Server Web Methods
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSUS: Server Web Service
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSUS: Update Regulation Web Methods
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WSusCertServer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WsusService
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services
10. From a command prompt and change directory to c:\windows\microsoft.net\framework\v2.0.50727
Then type the command : aspnet_regiis -i
11. From a command prompt, type: iisreset
12. Re-run the WSUS 3.0 installation and leveraging the Deployment guide.
Deploying Microsoft Windows Server Update Services 3.0 SP1 (http://technet.microsoft.com/en-us/library/cc720507.aspx)
If you have WSUS 2.0 installed on Windows 2000 SP4 server and not able to synchronize and approve the updates once the SUSDB size approaches to 2 GB. Then It may be 2 GB limit of WMSDE database.
In such cases you may get the following logs:
1. Event ID 17055 from source MSSQLSERVER.
Description: CREATE/ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 2048 MB per database.
2. Event ID 17052 from source MSSQLSERVER.
Description: Could not allocate space for object 'tbXml' in database 'SUSDB' because the 'PRIMARY' filegroup is full.
You can follow the methods mentioned in the following article:
http://support.microsoft.com/default.aspx/kb/909456
In the above mentioned article, Method 2 from this article says:
"Upgrade the WSUS 2.0 installation to WSUS 2.0 Service Pack 1 (SP1). WSUS 2.0 SP1 upgrades WMSDE Service Pack 3 (SP3) to WMSDE Service Pack 4 (SP4) and fixes the 2-GB size limit."
I have seen the case where we installed the SP1 and it finished successfully without any error message. However we were still getting the same issue. We checked the WSUS 2.0 build version. It was 2.0.0.2620 (Which is WSUS 2.0 SP1 build)
You can check the version of the WMSDE on the server.
Run the following command using OSQl utility:
OSQL.exe -S machinename -E -Q "select @@version"
It might show the WMSDE SP3 build number(8.00.760) and it is known that 8.00.760 version has a 2GB database limit.
If this is the case then, download WMSDE SP4 from the following URL:
http://www.microsoft.com/downloads/details.aspx?FamilyID=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5&displaylang=en
Download the exe file.
Extract it and then installed it on the server.
After installation, rebooted the server.
Now you should see the WMSDE version as 8.00.2039. This version fixes the 2 GB limit.
Another workaround is to run this command to minimize the database (SUSDB) size
c:\programfiles\update services\tools> WSUSutil Deleteunneededrevisions
If you use an MSDE database in your WSUS implementation (for example, if you are using WSUS on a server running Windows 2000), you might need to run this command periodically when the database reaches its 2-GB limit because once the database is full, you cannot synchronize new updates to your server, add new computers, or import events from existing client computers.
Reference: Managing WSUS from the Command Line (http://technet.microsoft.com/en-us/library/cc720466.aspx)
NOTE: WSUS 2.0 SP1 support is ending on 30th April, 2009 (http://technet.microsoft.com/en-us/wsus/bb466202.aspx). So we should plan to migrate the WSUS 2.0 SP1 to WSUS 3.0 SP1 now. (WSUS 3.0 RTM support has already been ended in Feb 2009)
CAUSE:
In some cases the software hive exceeds 30 MB or higher.
RESOLUTION:
We've seen the case where we got multiple keys under the following registry tree
HKEY_LOCAL_MACHINE\Test\Macromedia\ColdFusion\CurrentVersion\Clients
That leads the Software hive to grow enormously and crash the system.
1) Take the backup of the Software hive.
2) Delete the "clients" key and compact the Registry by exporting to (*.hiv) file and replace the existing Software Hive to bring the system back.
Issue: When trying to add a server to SCVMM it may generate the following error:
Error (2923)
A malformed response was received trying to contact the agent on <Server_Name> server.
(The operation completed successfully (0x0)
Cause:
The problem is with the Broadcom network adapters having their own wmi providers. In this case, there is a class BRCM_NetworkAdapter which derives from
Win32_NetworkAdapter. When VMM tries to enumerate its properties, since we don’t have any wrapper for it and we fail.
Resolution: The issue was resolved by removing the namespace that gets
installed as a part of the Network Driver installation package with Broadcom NIC
software.
When running updates from WSUS 3.0 SP1 we are seeing the following error messages in the Windows Update Agent Log File C:\Windows\WindowsUpdate.log
We see these messages on all of our target Windows 2003 SP2 x64 servers WindowsUpdate.
2009-01-21 08:50:02:878 816 f2c PT +++++++++++ PT:
Synchronizing server updates +++++++++++
2009-01-21 08:50:02:878 816 f2c PT + ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://slon123456.csfb.cs-group.com/ClientWebService/client.asmx
2009-01-21 08:50:03:284 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:346 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:362 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:378 816 f2c EEHndlr WARNING: Failed to
populate ServiceStartup entries in Cache: error 0x80070002
2009-01-21 08:50:04:518 816 f2c PT +++++++++++ PT:
Synchronizing extended update info +++++
Cause:
When the Windows Update service starts up, we look to see whether there’s a registry key named
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Setup\ServiceStartup.
If that key doesn’t exist, then everything is fine, and there’s nothing to copy.
If that key does exist, we look to see whether it contains any keys.
- If it doesn’t, then everything is fine, and there’s nothing to copy.
- If it does, then we expect each of those keys to contain two string values, one
named CacheFile and one named TargetFile.
Then:
- If a given key contains the CacheFile and TargetFile values as expected, then we use those values to determine what file copy operations we need to do.
- If a given key is missing either the CacheFile or the TargetFile key or both, then we wind up throwing the 0x80070002 error.
So this is only a problem if there actually has been a self-update, and we actually do need to copy some files, and we can’t because a key has somehow gotten created in the ServiceStartup key that does not contain the CacheFile and TargetFile values we’re looking for.
Key named WOW64 can be seen in this area, only on 64-bit machines. That key didn’t contain CacheFile or TargetFile values, so it would result in the ServiceStartup 0x80070002 error being logged at startup.
Resolution:
In this set of circumstances, if you delete either the ServiceStartup key or just the WOW64 key, you should see the 0x80070002 warnings go away, with no effect on the system’s operation.
ISSUE : Internet connection does not work after the windows updates.
CAUSE : If customer has Zone Alarm product installed on the system, it is causing the issue.
RESOLUTION : Workaround from Zone alarm site. http://download.zonealarm.com/bin/free/pressReleases/2008/LossOfInternetAccessIssue.html
|
Workaround to Sudden Loss of Internet Access Problem |
|
|
|
|
|
Overview : Microsoft Update KB951748 is known to cause loss of internet access for ZoneAlarm users on Windows XP/2000. Windows Vista users are not affected. |
|
Impact : Sudden loss of internet access |
|
Platforms Affected : ZoneAlarm Free, ZoneAlarm Pro, ZoneAlarm AntiVirus, ZoneAlarm Anti-Spyware, and ZoneAlarm Security Suite |
|
Recommended Actions -
Download and install the latest versions which solve the loss of internet access problem here:
ZoneAlarm Internet Security Suite
ZoneAlarm Pro
ZoneAlarm Antivirus
ZoneAlarm Anti-Spyware
ZoneAlarm Basic Firewall
- or follow the directions below.
Option 1: Move Internet Zone slider to Medium
- Navigate to the "ZoneAlarm Firewall" panel
- Click on the "Firewall" tab
- Move the "Internet Zone" slider to medium
Option 2: Uninstall the hotfix
- Click the "Start Menu"
- Click "Control Panel", or click "Settings" then "Control Panel"
- Click on "Add or Remove Programs"
- On the top of the add/remove programs dialog box, you should see a checkbox that says "show updates". Select this checkbox
- Scroll down until you see "Security update for Windows (KB951748)"
- Click "Remove" to uninstall the hotfix
|
We are seeing cases with a Stop 0x8E errors after an update to Symantec Antivirus 10.
Prior to setting the trap frame the stack will normally look like
STACK_TEXT:
f642633c 8085b4af 0000008e c0000005 f5148223 nt!KeBugCheckEx+0x1b f6426700 808357a4 f642671c 00000000 f6426770 nt!KiDispatchException+0x3a2
f6426768 80835758 f64267e4 f5148223 badb0d00 nt!CommonDispatchException+0x4a f6426780 8089c27a 863cf008 e53e74d0 e1fa5008 nt!KiExceptionExit+0x186
f64267e4 f6e7d4ff f6eaafb8 e5330428 e2c95755 nt!ExFreePoolWithTag+0x277
WARNING: Stack unwind information not available. Following frames may be wrong.
f6426814 f6e7ddb6 f6426840 f642683c f642684c savrt+0x234ff 00000000 00000000 00000000 00000000 00000000 savrt+0x23db6
After setting the trap frame, the stack and registers will normally look like
eax=75100824 ebx=e53e74d0 ecx=f50f7400 edx=e2c95755 esi=e5330428 edi=f642683c
eip=f5148223 esp=f64267e4 ebp=f64267e4 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
navex15+0x51223:
f5148223 8138dedaaeab cmp dword ptr [eax],0ABAEDADEh ds:0023:75100824=????????
*** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
f64267e4 f6e7d4ff f6eaafb8 e5330428 e2c95755 navex15+0x51223
f6426814 f6e7ddb6 f6426840 f642683c f642684c savrt+0x234ff 00000000 00000000 00000000 00000000 00000000 savrt+0x23db6
At this point, we believe the system is crashing due to a version mismatch between an updated version of Navex15 and older versions of Savrt and symevent.
Image name: navex15.sys Timestamp: Mon Feb 11 13:41:31 2008 (47B0A4EB)
Image name: SYMEVENT.SYS Timestamp: Tue Apr 18 19:16:26 2006 (4445815A)
Image name: savrt.sys Timestamp: Mon Dec 19 22:24:48 2005 (43A78790)
The versions listed for Symevent and Savrt may be different than the ones listed, but so far they have all been at least a year older than Navex15.sys.
Customers should contact Symantec for support. As a workaround we can try the following
Have the customer uninstall Symantec Antivirus 10 and then reinstall the updated version.
This should hopefully put the correct version of files in place.