TimmG6376

Just FYI you can also check for the existence of HKLM:/Software/Microsoft/Windows/CurrentVersion/Uninistall/Office14.ProPlus to determine if Office 2010 is already installed. This assumes 32-bit Office and 32-bit OS or 64-bit Office and 64-bit OS. If 64-bit OS and 32-bit Office, the path is HKLM:/Software/Wow6432Node/Microsoft/Windows/CurrentVersion/Uninistall/Office14.ProPlus. You can determine OS architecture either by testing for the existence of the 'Program Files (x86)' folder or in Win 7 you can use WMI to check the OSArchitecture propery in Win32_OperatingSystem. The 'ProPlus' comes from the config.xml. You can use this to check for installation state of other Office products as well. For example, Visio is Office14.Visio and Project Professional is Office14.PrjPro. Just check the config.xml in the product installation source and you'll find the value you need. I've been working on a Powershell startup script to do our migration from 2007 to 2010 on Windows 7. Will post it when I get it done.

$ErrorActionPreference = "SilentlyContinue" #Replace with your computer OU $OU = "OU=Computers,DC=domain,DC=local" $LdapFilter = "(&(objectCategory=computer))" $objDomain = New-Object System.DirectoryServices.DirectoryEntry("LDAP://"+$OU) $objADsearcher = New-Object System.DirectoryServices.DirectorySearcher $objADsearcher.SearchRoot = $objDomain $objADsearcher.filter = "$LdapFilter" $colProplist = "cn" foreach ($i in $colPropList){$objADsearcher.PropertiesToLoad.Add($i)} $objResults = $objADsearcher.findall() $AllComputers = @() $ComputerObj = @() $ComputerObj = New-Object psObject Foreach ($objresult in $objResults ) { $ComputerObj = @() $ComputerObj = New-Object psObject $CN = ($objResult.GetDirectoryEntry().cn).ToString().TrimEnd() $ComputerObj | Add-Member -MemberType NoteProperty -Name "CN" -Value $CN -Force If ($result = test-connection -computername $CN -Quiet -Count 2 -TimeToLive 5){ $ComputerObj | Add-Member -MemberType NoteProperty -Name "Model" -Value ((Get-WmiObject -class win32_computersystem -computername $CN).model) -Force $ComputerObj | Add-Member -MemberType NoteProperty -Name "Manufacturer" -Value ((Get-WmiObject -class win32_bios -computername $CN).manufacturer) -Force $ComputerObj | Add-Member -MemberType NoteProperty -Name "Serial" -Value ((Get-WmiObject -class win32_bios -computername $CN).serialnumber) -Force } Else { $ComputerObj | Add-Member -MemberType NoteProperty -Name "Model" -Value "Not Found" -Force $ComputerObj | Add-Member -MemberType NoteProperty -Name "Manufacturer" -Value "Not Found" -Force $ComputerObj | Add-Member -MemberType NoteProperty -Name "Serial" -Value "Not Found" -Force } $ComputerObj | ft $AllComputers += $ComputerObj } $file = "ComputerInventory_" + (Get-Date -Format "yyyyMMdd") + ".csv" $AllComputers |Sort-Object "CN" | Export-Csv "$file" -NoTypeInformation Requires Powershell. I'm using 2.0 but I don't think there is anything in there that won't work in 1.0. Haven't tested for backwards compatibility. Finds computers in AD using designated OU as starting point. Sends ping to verify host is online before querying WMI. Exports results to CSV. Having an issue with a couple of PCs where access to WMI is being denied. In these cases the fields for Model, Serial, Manufacturer will be blank instead of "Not Found". I imagine it is an issue with WMI on those workstations and will have to investigate.

There are a few NICs that can also exhibit this behaviour due to GP trying to process before link negotiation has completed. See the post from Brent Hu at the link below (about 11 posts down the page). Windows 7 Slow to Log on with Re-Directed Folders - Windows Server 2008

Another factor is that while in general the 32-bit flavor of Windows 7 is more secure than previous MS Operating Systems, going 64-bit takes it to another level due to Kernel Patch Protection. We are almost completely transitioned from XP to Windows 7 Pro x64. Only one legacy app remains that will not run locally on the workstations and for that we published the app from our XenApp farm. Only a small group of users need the application and even they do not use it very often. Report: Windows 7 almost five times more secure than XP | Security - CNET News

Ok I had completely ignored Windows 7 SP1 because I had read in multiple threads that it had no effect on this issue. We have not deployed SP1 as of yet, but unrelated to this issue I decided that it was time to install it on my PC and see if any issues arise. Incredibly after rebooting the NetLogon errors stopped. Disabled my GPO that modifies the registry. Set the registry back to defaults (DhcpConnForceBroadcastFlag = 0; deleted DhcpConnEnableBcastFlagToggle ). Cleared my System log. After another reboot still no NetLogon errors. I do still have the firewall disabled so that is my next test. CORRECTION: Seems to be a combination of SP1, completely the disabling firewall (domain,private,public), and the forcing broadcast flag via the registry. With all three of those I no longer get NetLogon errors on a wired connection. Will have to check wireless tomorrow.

I blocked Chrome using a combination of Software Restriction polices and Google Update for Enterprise ADM templates (link) I created Software Restriction rules to disallow the following: %LocalAppData%\Google\Chrome\Application\*\Installer\setup.exe %LocalAppData%\Google\Chrome\Application\chrome.exe %LocalAppData%\Temp\CR_*.tmp\setup.exe C:\Documents and Settings\%username%\Local Settings\Application Data\Google\Chrome\Application\*\Installer\setup.exe C:\Documents and Settings\%username%\Local Settings\Application Data\Google\Chrome\Application\chrome.exe C:\documents and settings\%username%\local settings\temp\cr_*.tmp\setup.exe chrome.exe chrome_installer.exe chromesetup.exe gears-chrome-opt.msi Not perfect solution as a savvy user can download the installer and rename it to circumvent the policy. I also created a 'Chrome Allowed' security and group which is denied access to this policy. This was because we had a small group of users doing web development that needed to have Chrome installed for testing purposes. Adding users to that group prevents the Software Restriction policy from being applied thus allowing Chrome to be installed/run.

Wired gigabit. Not too concerned about the wireless connections as everyone with a laptop docks when at their desks so wireless is only used occasionally or for guests. I've tried the DHCPConnForceBroadcastFlag and DhcpConnEnableBcastFlagToggle to no avail. If it is working for you though I will submit this Powershell script that will allow you to push these entries out to multiple machines. As with any script use at your own risk and test before using in production # Replace with your subnet $IpSubnet = "10.1.1." # Use WMI query to get GUID for network adapter with IP address matching the IP subnet configured above $NIC = Get-WmiObject -query "select settingid, ipaddress from win32_networkadapterconfiguration WHERE IPEnabled = 'True'" | ? { $_.IpAddress -match $IpSubnet } $GUID = $NIC.SettingID.ToString() #Use GUID to set registry path to interface key $RegPath = "HKLM:\System\CurrentControlSet\services\TCPIP\Parameters\Interfaces\" + $GUID $RegKey = Get-Item $RegPath # Sets DhcpConnForceBroadcastFlag property value to 1 Set-ItemProperty $RegKey.PSPath -name DhcpConnForceBroadcastFlag -Value 1 # Checks for existence of DhcpConnEnableBcastFlagToggle property # If it does not exist create the property with value 0 # If it does exist set the value to 0 If ((Get-ItemProperty $RegKey.PSPath -Name DhcpConnEnableBcastFlagToggle -ErrorAction SilentlyContinue) -eq $null ) { New-ItemProperty $RegKey.PSPath -Name DhcpConnEnableBcastFlagToggle -Value 0 -PropertyType DWORD } Else { Set-ItemProperty $RegKey.PSPath -Name DhcpConnEnableBcastFlagToggle -Value 0 } I created a GPO on a test OU and configured this script as a Shutdown script. It configures the registry as desired, however, I'm still getting the NetLogon errors with my test machine.

I have mitigated the Group Policy processing issues by tweaking the following GPO settings: Computer Configuration/Administrative Templates/System/Group Policy/Startup policy processing wait time Computer Configuration/Administrative Templates/System/Logon/Always wait for the network at computer startup and logon Computer Configuration/Administrative Templates/System/Net Logon/Expected dial-up delay on logon None of the suggested workarounds for the NetLogon errors have worked. Disabling the firewall did nothing. The DHCPConnForceBroadcastFlag can be implemented but the global setting only applies if the entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ is deleted.