Normally, if you want to install Office Communicator Mobile on your phone you have to do so by running an MSI on you PC, then sync your phone to install the application through ActiveSync. If you prefer to just install directly from the .cab file, you can browse to www.getcomo.com (this is a Microsoft website) on your mobile phone, choose your phones OS, then install the .cab directly from the website, no PC or syncing involved!
A CPA client of ours runs a proprietary audit software called ProSystems Engagement that allows auditors to sync their data to each other. The auditors were having trouble syncing the data between their systems. The customer has some older Lenovo (T-42 and T-60/61) laptops and some new Lenovo W700 laptops. Their older laptops could sync with each other and their new laptops could sync to the old laptops. But neither could sync to the new laptops. I worked with the software vendor and ran about every query and test they had trying to pinpoint the cause. But was unable to determine why the new laptops could not be synced too. [more]
Luckily, the customer had order a new W-700 that I needed to setup. So using it as a test I began setting up the laptop as per their checklist. At every stage I tested the sync process. The last thing to be installed was the AT&T Communication management software for their 3G modems. (which they need) After completing the install Prosystems sync would not work. I uninstalled the AT&T software and sync worked. I reinstalled and it broke. I looked through the software settings and found that it installs a ByteMobile Acceleration program. I had previously, on another system, deselect the option to use the acceleration program and it still would not sync. I choose to uninstalled just the ByteMobile software and the sync worked, as well as the AT&T software and 3G modem.
The Bytemobile acceleration client is used to increased data reduction and speed-up the download process. It offers bidirectional optimization for dramatically reduced traffic on the uplink. It intercepts and optimizes all TCP network traffic generated from and received by the device. The software supports protocol-agnostic compression, lossy and lossless image file reduction, and delta compression techniques to ensure that the same data is not downloaded to the client repeatedly. It claims to preserves interoperability with third-party Windows applications such as internet security, personal firewall and VPN software. Client applications such as web browsers and remote applications such as web servers are suppose to be unaware of the application between them and operate as if communicating directly with each other. Since the sync process compare and transfers the same data throughout the process the acceleration client was causing the sync to fail.
I cloned a Windows Desktop XP machine and could not access the machine via RDP. I found that if I edited the registry with a key AllowDirectRDP=True, then I could RDP to the desktop. After researching the problem, I found that this behavior is “by design” for Virtual Desktop Manager “managed” machines. However, I do not believe the original machine was managed by the VDM, but it could have had roots in such a machine.
Here is the relevant KB article from VMWare. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006042
I had several issues getting my PGP Desktop software to correctly talk to the PGP management server. First, I went through the default install without any problems. I configured my private/public keys and encrypted my disk. I got word from Chris Brewer later, however, that I wasn’t showing up in the PGP server. We both tried several things to get me in. I tried importing my private key to the server, but it failed and the log was saying I wasn’t part of the managed domain. We eventually called PGP support and got my PGP Desktop software reconfigured to use my domain credentials and register with the server. Turns out I should have done a custom install and targeted our PGP management server… rather than the default stand-alone install. I was now showing on the server, but I was showing to be decrypted. My disk, however, was encrypted. I decided to decrypt and re-encrypt now that I was talking to the server. This was about a 24-hr process. After re-encryption and multiple reboots… I still was showing to be “unencrypted” on the server. The PGP support guy had mentioned the Mac client had some issues reporting properly to the management server and he had a special build he could let us try. Once we got it, I installed it and rebooted and everything was fixed.
Symantec Endpoint Protection (SEP) allows additional locations to be defined per client-group. The main purpose of these is usually to define LiveUpdate settings when the client is not on the network. Although there are many rule variations to define when the client auto-switches to a secondary location, one common rule-setting is to switchover when the client simply cannot communicate with the management server. Occasionally, you may have reason to define a second location for your server group(s). If so, be careful not to have an additional location using the rule mentioned above for your terminal-server group (either explicitly or through inheritance). Doing so can make your terminal-server SEP clients go 'partially offline' - meaning they show offline locally and do not seem to enforce some policy settings, but continue to apply definition updates and show online in the management console. A symptom of this behavior that is easy to spot is the SEP icon not displaying in the system tray (assuming you don't have policies defined to intentionally hide it). Rebooting the terminal server or restarting SMC will resolve the issue temporarily, but it will come back randomly. This issue has been seen in a production environment using SEP 11.0.4-builds on Windows 2003 SP2 Terminal Services.
A client of ours uses the Cybernet iONE all in one PCs for customer internet stations at several of their locations. One oddity of these machines is that they ship with dual Gigabit onboard NICs. On these internet stations we typically use just one and disable the other NIC. While building out a particular machine, I needed to install several pieces of software that we deploy via Group Policy Software Installation. The problem is that any time I would attempt to deploy the software via Group Policy, it would fail and I would see event ID 1054 in the event logs… “Windows cannot obtain the domain controller name for the computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted. Data: (unavailable)”. Everything else was working fine. The machine was a member of the domain, I could ping the domain controller that DHCP had assigned to the machine, I could resolve internal and external addresses, gpresult showed that the PC was successfully linked to the software installation OU, etc. [more]
After conducting some research on this error and on these machines, it turns out the problem was that the onboard Broadcom gigabit NIC was taking too long to auto-negotiate its link speed, creating a “race condition” between the TCP/IP protocol and the NIC driver when they try and register with the MS Nework Driver Interface Specification. The local Userenv process (what actually performs GP’s instructions) would attempt to install the software before the NIC was fully available, thereby causing it to fail when it would attempt to run the assigned MSI over the network. Here’s how to rig the race so that the NIS driver always wins the “race”. There is a MS hotfix available for this along with a more detailed problem description at http://support.microsoft.com/kb/840669. After installing this hotfix you must add the DWORD registry entry GpNetworkStartTimeoutPolicyValue in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and set the value of that DWORD entry to the number of seconds you would like the OS to delay processing Group Policy Startup scripts.
I was assisting a vendor with a software update at a client site that required .NET 3.5 SP1. An error keep popping up (“remote user install not available”) when I attempted to install .NET 3.5 SP1. RGBRast was listed as the problem child. I looked at group policy as many web post suggested.
(Computer Configuration: Administrative Templates: Windows Components:Windows Installer) (Disable Windows Installer) Set to "Disable"
The group policy was not set so I went ahead and disabled the setting to see if it would help, but it did not.
After researching more I found that with .NET 3.0 and up, the RGB Rast msi appears to be configured to do a per-user install, rather than per-machine. The server had the "Prevent per-user installs" Group Policy enabled which would cause the install to fail, preventing .Net 3.5 from installing. [more]
I modified the registry value
Key: HKLM\Software\Policies\Microsoft\Windows\Installer
Value: DisableUserInstalls
Data: 1
Type: REG_DWORD
And was then able to complete the .NET 3.5 SP1 installation as well as the database / program upgrade.
This seems to be something that my Windows Vista book did not mention about disk management in comparison with the past versions. Windows Vista/7/2008 Server have an improved Disk Management feature in that it allows you to shrink basic partitions. Whereas in the past we have had to use 3rd party utilities (such as gparted or partition magic) to resize drives, Windows has the option to shrink the partition size. Simply open up disk management and right click on the partition you wish to shrink and select “Shrink”.
Windows will calculate exactly how much it can shrink so that you can use the new unallocated space to make additional partitions. Limitations to this of course depend on where the data is currently stored on the disk. If it is scattered, you may be able to claim more by defragmenting and moving your data towards the first sectors of the disk.
I have been working on VMware vSphere v4 for the last few days and have found that enabling jumbo frames support is not as intuitive as the admin guide makes it sound. The process goes something like this.
Both of these are very straight forward and simple to do, but here is where it gets a little tricky. vSphere v4 jumbo frame support for the iSCSI network must be enabled with the CLI. Two things must be done. You must enable jumbo frames on the vSwitch and then able it on the VMkernel port/ports. The command to enable JF enable on the vSwitch looks like this: [more]
esxcfg-vswitch -m <MTU> <vSwitch>
In my case, I wanted a 9000 MTU (9KB) for vSwitch1, so it was ‘esxcfg-vswitch -m 9000 vSwitch1’ . All good so far. Now, I needed to JF enable the VMkernel port. Admin guide says this is the command
esxcfg-vmknic -a -I <ip address> -n <netmask> -m <MTU> <port group name>
So my command looked something like this esxcfg-vmknic -a -I 192.168.155.21 -n 255.255.255.0 -m 9000 “iSCSI VMkernel”
When I ran this command, it said that this port group didn’t exist. Exactly…that is why I am running this command…to create the VMkernel port and associated port group. After MUCH troubleshooting, I finally found that the following sequence WILL work. It must have something to do with the way the port groups and their associated identifiers are created.
Using Explorer from my laptop has been frustratingly slow any time network drives were visible in the left-hand pane. Any time I'd switch to a different program and switch back, it was a slow process (15-30 seconds) of Explorer enumerating each network drive, with a visible delay in the seconds range for each network drive. While researching network performance for another customer, I came across a way to dramatically reduce the amount of time Explorer takes to enumerate these drive letters. Apparently, when Explorer connects to a network resource, it searches the networked computer for scheduled tasks. You can turn this off by deleting the following registry key and rebooting: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\
Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}
After making that change Explorer now enumerates the drives in five seconds or so.