Sunday, May 24, 2015

GFI Archiver: How to move search indexes

To move the search index of an Archive Store from GFI Archiver:
  1. Open the GFI Archiver web page
  2. Navigate to: Configuration > Archive Stores
  3. Select an Archive Store and click on the Summary button
  4. Take a note of the Path to search index
    • For example: C:\Program Files\GFI\Archiver\Indexes\2015 Jan
  5. Stop the GFI Archiver Search service
  6. Copy the entire index folder from step 4 to the new location
    • For example, copy: C:\Program Files\GFI\Archiver\Indexes\2015 Jan
    • to
    • E:\Archiver\Indexes\2015 Jan
  7. Start the GFI Archiver Search service
  8. Open the GFI Archiver web page
  9. Navigate to: Configuration > Archive Stores
  10. Select the same Archive Store again and click on the Edit button
  11. Complete wizard changing the Search Index location to the new location
  12. Confirm the index is online (Configuration > Archive Stores) and searchable
  13. Delete old search index folder from disk

Tuesday, May 19, 2015

Configure Your Windows 7 System to Run Legacy Apps in a Virtualized Windows XP Environment

Windows XP Mode is an optional download for the Professional, Enterprise, and Ultimate editions of Windows 7. It provides a licensed copy of Windows XP with Service Pack 3, saved in Virtual Machine Hard Drive Image (.vhd) format. When run in Windows Virtual PC, or another compatible program, this virtualized installation of Windows XP lets you run applications that might not run well in Windows 7. Windows XP Mode is also handy if you have an older device with a proprietary driver that hasn’t been updated for Windows Vista or Windows 7. If it worked great in Windows XP but doesn’t work in Windows 7, give it a try in Windows XP Mode.

NOTE: Windows Virtual PC requires a computer with hardware-assisted virtualization. That means the CPU has to support either Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V). In addition, hardware virtualization must be enabled in the BIOS. Both Intel and AMD offer an array of processor options, some that support hardware virtualization and some that do not. If you’re buying a system expressly for the purpose of running Windows XP Mode, be sure it meets these requirements. 

Download and Install Windows XP Mode
Setting up Windows XP Mode requires two free downloads—first is a small download that enables the Windows Virtual PC host program, followed by a separate download that installs, configures, and activates the licensed copy of Windows XP SP3. Follow these steps:
1. Go to the Windows Virtual PC site and click Download Windows XP Mode and Windows Virtual PC.
2. Select your Windows 7 system type (32-bit or 64-bit) and language.
3. Follow the Web site’s instructions to download and install Windows Virtual PC, and then Windows XP Mode.
4. Restart your system.
5. Launch Windows XP Mode by opening the Start menu, choosing All Programs, clicking Windows Virtual PC, and then clicking Windows XP Mode.
6. Accept the license agreement and enter a password for the default administrative account. If you select Remember Credentials (Recommended) in this dialog box, whenever you launch Windows XP Mode from your Windows 7 desktop or Start menu, you’ll be logged on automatically with the saved credentials.
7. Allow the setup process to complete, then customize and secure your new Windows XP installation to suit your needs and preferences. If you create additional user accounts, be aware that the system will let you create accounts without passwords but won’t let you log on to those accounts.

By default, Windows Virtual PC shares your computer’s optical drives with Windows 7. But while the virtual environment is running, AutoRun is disabled. To install an application from a CD or DVD in Windows XP Mode, you must run the virtual environment, insert the disc, open My Computer in Windows XP, and run the application’s setup program.

After you have installed a program in this manner, you can run it “seamlessly” by launching it from the Windows 7 Start menu. It will have a Start-menu shortcut in the Windows XP Mode Applications folder. Applications installed in Windows XP Mode and launched from the Windows 7 Start menu run on the Windows 7 desktop, without visible elements of Windows XP Mode. Note that the applications take longer to launch, because the virtual environment must be initialized.  

Windows Recovery Technical Reference

Windows Recovery Environment (Windows RE) is an extensible recovery platform based on Windows Preinstallation Environment (Windows PE). When the computer fails to start, Windows automatically fails over into this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an unbootable Windows Vista installation. Furthermore, Windows RE is a starting point for various tools for manual system recovery. The primary audience of this technology includes original equipment manufacturers (OEMs), original device manufacturers (ODMs), and corporate IT professionals.

In this Section

Monday, May 18, 2015

Determine Bandwidth Options to Use for Your Deployment

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server Update Services
No matter the amount of network bandwidth available, WSUS offers features that allow you to shape the deployment to best fit your organization's needs. The decisions you make about how to synchronize with Microsoft Update have a dramatic effect on the efficient use of bandwidth. Use the following sections to understand WSUS features for managing bandwidth.

Deferring the Download of Updates

WSUS offers you the ability to download update metadata at a different time from the update itself during synchronizations. In this configuration, approving an update triggers the download of all the files used to install that particular update on a computer. This saves bandwidth and WSUS server disk space, because only updates that you approve for installation are downloaded in full to the WSUS server. You can test the files prior to deploying them on your network, and your client computers download the updates from the intranet. Microsoft recommends deferring the download of updates, since it makes optimal use of network bandwidth.
Deferred Downloads of Updates If you have a chain of WSUS servers, it is recommended that you do not chain them too deeply, for the following reasons:
  • In a chain of WSUS servers, WSUS automatically sets all downstream servers to use the deferred download option that is selected on the server directly connected to Microsoft Update. You cannot change this configuration. The entire chain of WSUS servers must either defer the download of updates or download both metadata and updates during synchronizations.
  • If you have deferred downloads enabled and a downstream server requests an update that has not been approved on the upstream server, the downstream server’s request triggers a download on the upstream server. The downstream server then downloads the content on a subsequent synchronization, as shown in the "Deferred Downloads Using Multiple WSUS Servers" illustration. If you have a deep hierarchy of WSUS servers using deferred downloads, there is greater potential for delay as content is requested, downloaded, and then passed down the chain.
Deferred Downloads Using Multiple WSUS Servers For bandwidth savings, deferring downloads is particularly useful in conjunction with a special approval setting that only detects whether client computers require an update. With this kind of approval, the WSUS server does not download the update and clients do not install the update. Instead, clients just determine if they need the update. If they do, they send an event to the WSUS server, which is recorded in a server report. If you see that your clients require updates that were approved for detection, you can then approve them for installation.
This combination of deferring downloads and detection approvals allows an administrator to download only the updates required by the client computers that are connected to the WSUS server. WSUS allows you to automate this scenario by creating a rule on the WSUS server that automatically approves all new updates for detection. For more information about different types of approvals and creating automatic approval rules, refer to the Windows Server Update Services Operations Guide at http://technet2.microsoft.com/windowsserver/en/library/9b65850d-17a0-440e-9cad-2eb881011f5f1033.mspx?mfr=true.
If you chose to store updates locally during the WSUS setup process, deferred downloads are enabled by default. You can change this option manually. See Configure Advanced Synchronization Options for step-by-step procedures.

Filtering Updates

WSUS offers you the ability to choose only the updates your organization requires during synchronizations. You can limit synchronizations by language, product, and type of update.
In a chain of WSUS servers, WSUS automatically sets all downstream servers to use the update filtering options that are selected on the server directly connected to Microsoft Update. In other words, you can only set a filter for updates on the upstream server. You cannot change this configuration. The entire chain of WSUS servers must all use the same update filters.
By default WSUS downloads Critical and Security Updates for all Windows products in every language. Microsoft recommends that you limit languages to only those you need, to conserve bandwidth and disk space. To change language options, see Configure Advanced Synchronization Options. To change product and update classification options, see Select Products and Classifications.

Using Express Installation Files

The express installation files feature is an update distribution mechanism. You can use express installation files to limit the bandwidth consumed on your local network, but at the cost of bandwidth consumption on your Internet connection. By default, WSUS does not use express installation files. To better understand the tradeoff, you first have to understand how WSUS updates client computers.
Updates typically consist of new versions of files that already exist on the computer being updated. On a binary level these existing files might not differ very much from updated versions. The express installation files feature is a way of identifying the exact bytes that change between different versions of files, creating and distributing updates that include just these differences, and then merging the original file with the update on the client computer. Sometimes this is called delta delivery because it downloads only the difference, or delta, between two versions of a file.
When you distribute updates by using this method, it requires an initial investment in bandwidth. Express installation files are larger than the updates they are meant to distribute. This is because the express installation file must contain all the possible variations of each file it is meant to update.
The upper part of the "Express Installation Files Feature" illustration depicts an update being distributed by using the express installation files feature; the lower part of the illustration depicts the same update being distributed without using the express installation files feature. Notice that with express installation files enabled, you incur an initial download three times the size of the update. However, this cost is mitigated by the reduced amount of bandwidth required to update client computers on the corporate network. With express installation files disabled, your initial download of updates is smaller, but whatever you download must then be distributed to each of the clients on your corporate network.
Express Installation Files Feature The file sizes in the "Express Installation Files Feature" illustration are for illustrative purposes only. Each update and express installation file varies in size, depending on what files need to be updated. Further, the size of each file actually distributed to clients by using express installation files varies depending upon the state of the computer being updated.
ImportantImportant
Although there are some variables with express installation files, there are also some things you can count on. For example, express installation files are always bigger in size than the updates they are meant to distribute. As far as bandwidth goes, it is always less expensive to distribute updates using express installation files than to distribute updates without.
Not all updates are good candidates for distribution using express installation files. If you select this option, you obtain express installation files for any updates being distributed this way. If you are not storing updates locally, you cannot use the express installation files feature. By default, WSUS does not use express installation files. To enable this option, see Configure Advanced Synchronization Options.

Background Intelligent Transfer Service

WSUS uses Background Intelligent Transfer Service 2.0 (BITS) for all its file-transfer tasks, including downloads to clients and server synchronizations. BITS is a Microsoft technology that allows programs to download files by using spare bandwidth. BITS maintains file transfers through network disconnections and computer restarts. For more information about BITS, see the BITS documentation on the MSDN site at http://go.microsoft.com/fwlink/?LinkId=15106.

Updated List of OS Version Queries for WMI Filters

The WMI filters use a query to scope down the application of the Group Policy Object applicability. Here’s what a typical WMI OS filter looks like:
WMI filter
select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND OSArchitecture = "64-bit"
WMI Win32_OperatingSystem ProductType Tips:
ProductType 1 = Desktop OS
ProductType 2 = Server OS – Domain Controller
ProductType 3 = Server OS – Not a Domain Controller
WMI Win32_OperatingSystem Version Number Tips:
5.1 – Windows XP
5.2 – Windows Server 2003
5.2.3 – Windows Server 2003 R2
6.0 – Windows Vista & Windows Server 2008
6.1 – Windows 7 & Windows Server 2008 R2
6.2 – Windows 8 & Windows Server 2012
6.3 – Windows 8.1 & Windows Server 2012 R2
To create your own WMI filters, here is an updated list of WMI filter queries from Window XP – Windows 8.1 and from Server 2003 to Server 2012 R2.
IMPORTANT DISCLAIMER:
Always test your Group Policies and WMI filters before deploying.

DESKTOPS

ANY WINDOWS DESKTOP OS

  • Any Windows Desktop OS – Version 1
    select * from Win32_OperatingSystem WHERE ProductType = "1"
  • Any Windows Desktop OS – Version 2 (better for Win7 sometimes)
    select * from Win32_OperatingSystem WHERE (ProductType <> "2") AND (ProductType <> "3")
  • Any Windows Desktop OS – 32-bit
    select * from Win32_OperatingSystem WHERE ProductType = "1" AND NOT OSArchitecture = "64-bit"
  • Any Windows Desktop OS – 64-bit select * from Win32_OperatingSystem WHERE ProductType = "1" AND OSArchitecture = "64-bit"

WINDOWS XP

  • Windows XP
    select * from Win32_OperatingSystem WHERE (Version like "5.1%" or Version like "5.2%") AND ProductType="1"
  • Windows XP – 32-bit
    select * from Win32_OperatingSystem WHERE (Version like "5.1%" or Version like "5.2%") AND ProductType="1" AND NOT OSArchitecture = "64-bit"
  • Windows XP – 64-bit
    select * from Win32_OperatingSystem WHERE (Version like "5.1%" or Version like "5.2%") AND ProductType="1" AND OSArchitecture = "64-bit"

WINDOWS VISTA

  • Windows Vista
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="1"
  • Windows Vista – 32-bit
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"
  • Windows Vista – 64-bit
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="1" AND OSArchitecture = "64-bit"

WINDOWS 7

  • Windows 7
    select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1"
  • Windows 7 – 32-bit
    select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"
  • Windows 7 – 64-bit
    select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND OSArchitecture = "64-bit"

WINDOWS 8

  • Windows 8 select * from Win32_OperatingSystem WHERE Version like "6.2%" AND ProductType="1"
  • Windows 8 – 32-bit
    select * from Win32_OperatingSystem WHERE Version like "6.2%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"
  • Windows 8 – 64-bit
    select * from Win32_OperatingSystem WHERE Version like "6.2%" AND ProductType="1" AND OSArchitecture = "64-bit"

WINDOWS 8.1

  • Windows 8.1
    select * from Win32_OperatingSystem WHERE Version like "6.3%" AND ProductType="1"
  • Windows 8.1 – 32-bit select * from Win32_OperatingSystem WHERE Version like "6.3%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"
  • Windows 8.1 – 64-bit
    select * from Win32_OperatingSystem WHERE Version like "6.3%" AND ProductType="1" AND OSArchitecture = "64-bit"

SERVERS

ANY WINDOWS SERVER OS

  • Any Windows Server OS
    select * from Win32_OperatingSystem where (ProductType = "2") OR (ProductType = "3")
  • Any Windows Server OS – 32-bit
    select * from Win32_OperatingSystem where (ProductType = "2") OR (ProductType = "3") AND NOT OSArchitecture = "64-bit"
  • Any Windows Server OS – 64-bit
    select * from Win32_OperatingSystem where (ProductType = "2") OR (ProductType = "3") AND OSArchitecture = "64-bit"
  • Any Windows Server – Domain Controller
    select * from Win32_OperatingSystem where (ProductType = "2")
  • Any Windows Server – Domain Controller – 32-bit
    select * from Win32_OperatingSystem where (ProductType = "2") AND NOT OSArchitecture = "64-bit"
  • Any Windows Server – Domain Controller – 64-bit
    select * from Win32_OperatingSystem where (ProductType = "2") AND OSArchitecture = "64-bit"
  • Any Windows Server – Non-Domain Controller
    select * from Win32_OperatingSystem where (ProductType = "3")
  • Any Windows Server – Non- Domain Controller – 32-bit
    select * from Win32_OperatingSystem where (ProductType = "3") AND NOT OSArchitecture = "64-bit"
  • Any Windows Server – Non-Domain Controller – 64-bit
    select * from Win32_OperatingSystem where (ProductType = "3") AND OSArchitecture = "64-bit"

WINDOWS SERVER 2003

  • Windows Server 2003 – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="2"
  • Windows Server 2003 – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="3"
  • Windows Server 2003 – 32-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="2" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2003 – 32-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="3" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2003 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="2" AND OSArchitecture = "64-bit"
  • Windows Server 2003 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2%" AND ProductType="3" AND OSArchitecture = "64-bit"

WINDOWS SERVER 2003 R2

  • Windows Server 2003 R2 – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="2"
  • Windows Server 2003 R2 – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="3"
  • Windows Server 2003 R2 – 32-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="2" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2003 R2 – 32-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="3" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2003 R2 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="2" AND OSArchitecture = "64-bit"
  • Windows Server 2003 R2 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "5.2.3%" AND ProductType="3" AND OSArchitecture = "64-bit"

WINDOWS SERVER 2008

  • Windows Server 2008DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="2"
  • Windows Server 2008 – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="3"
  • Windows Server 2008 – 32-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="2" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2008 – 32-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="3" AND NOT OSArchitecture = "64-bit"
  • Windows Server 2008 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="2" AND OSArchitecture = "64-bit"
  • Windows Server 2008 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.0%" AND ProductType="3" AND OSArchitecture = "64-bit"

WINDOWS SERVER 2008 R2

  • Windows Server 2008 R2 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="2"
  • Windows Server 2008 R2 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="3"

WINDOWS SERVER 2012

  • Windows Server 2012 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "6.2%" AND ProductType="2"
  • Windows Server 2012 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.2%" AND ProductType="3"

WINDOWS SERVER 2012 R2


  • Windows Server 2012 R2 – 64-bit – DC
    select * from Win32_OperatingSystem WHERE Version like "6.3%" AND ProductType="2"
  • Windows Server 2012 R2 – 64-bit – non-DC
    select * from Win32_OperatingSystem WHERE Version like "6.3%" AND ProductType="3" 

Sunday, May 17, 2015

Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting

How Managed Service Accounts Work

The Windows Server 2008 R2 AD Schema introduces a new object class called msDS-ManagedServiceAccount. Create an MSA, examine its objectClass attribute, and notice the object has an interesting object class inheritance structure:
Computer
msDS-ManagedServiceAccount
organizationalPerson
Top
User
The object is a user and a computer at the same time, just like a computer account. But it does not have an object class of person like a computer account typically would; instead it has msDS-ManagedServiceAccount. MSA’s inherit from a parent object class of “Computer”, but they are also users. MSA objects do not contain new attributes from the Win2008 R2 schema update.
And this leads me to how MSA’s handle passwords – it’s pretty clever. An MSA is a quasi-computer object that utilizes the same password update mechanism used by computer objects. So, the MSA account password is updated when the computer updates its password (every 30 days by default). This can be controlled - just like a computer’s password - with the following two DWORD values:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
DisablePasswordChange = [0 or 1, default if value name does not exist is 0]
MaximumPasswordAge = [1-1,000,000 in days, default if value name does not exist is 30]
MSA’s, like computers, do not observe domain or fine-grained password policies. MSA’s use a complex, automatically generated password (240 bytes, which is 120 characters, and cryptographically random). MSA’s cannot be locked out, and cannot perform interactive logons. Administrators can set an MSA password to a known value, although there’s ordinarily no justifiable reason (and they can be reset on demand; more on this later).
All Managed Service Accounts are created (by default) in the new CN=Managed Service Accounts, DC=, DC= container. You can see this by configuring DSA.MSC to show “Advanced Features”:
image
image
As you will see later though, there isn’t much point to looking at this in AD Users and Computers because… wait for it… all your administration will be done through PowerShell. You knew that was coming, didn’t you?
MSA’s automatically maintain their Kerberos Service Principal Names (SPN), are linked to one computer at a time, and support delegation. A network capture shows a correctly configured MSA using Kerberos:
image
image

Implementing MSA’s

Forest and OS Requirements
To use MSAs you must:
  • Use Active Directory
  • Extend your AD schema to Windows Server 2008 R2
  • Host services using MSAs on Windows Server 2008 R2 and Windows 7 computers (MSAs cannot be installed on down-level operating systems)
  • PowerShell, AD PowerShell (part of the RSAT), and the .Net 3.5x framework enabled on any computers using or configuring MSAs
MSAs do not require a specific Forest Functional Level, but there is a scenario where part of MSA functionality requires a Windows Server 2008 Domain Functional Level. This means:
  • If your domain is Windows Server 2008 R2 functional level, automatic passwords and SPN management will work
  • If your domain is less than WIndows Server 2008 R2 Domain Functional Level, automatic passwords will work. Automatic SPN management will not work, and SPN’s will have to be maintained by administrators
Deployment
Using a new MSA always works in four steps:
1. You create the MSA in AD.
2. You associate the MSA with a computer in AD.
3. You install the MSA on the computer that was associated.
4. You configure the service(s) to use the MSA.
We begin by using PowerShell to create the new MSA in Active Directory. You can run this command on Windows Server 2008 R2 or Windows 7 computer that has the RSAT feature “Active Directory Module for Windows PowerShell” enabled. Perform all commands as an administrator.
1. Start PowerShell.
2. Import the AD module with:
Import-Module ActiveDirectory
3. Create an MSA with:
New-ADServiceAccount -Name -Enabled $true
image
4.    Associate the new MSA with a target computer in Active Directory:
Add-ADComputerServiceAccount -Identity -ServiceAccount
image
5. Now logon to the target computer where the MSA is going to be running. Ensure the following features are enabled:
  • Active Directory Module for Windows PowerShell
  • .NET Framework 3.5.1 Feature
image
image
6. Start PowerShell.
7. Import the AD module with:
Import-Module ActiveDirectory
8. Install the MSA with:
Install-ADServiceAccount -Identity
image
Note: Besides being a local administrator on the computer, the account installing the MSA needs to have permissions to modify the MSA in AD. If a domain admin this "just works"; otherwise, you would need to delegate modify permissions to the service account's AD object. 
9. Now you can associate the new MSA with your service(s).
The GUI way:
a. Start services.msc.
b. Edit your service properties.
c. On the Log On tab, set “This Account” to the domain\name$ of your MSA. So if your MSA was called “AskDS” in the “contoso.com” domain, it would be:
contoso\askds$
d. Remove all information from Password and Confirm password – they should not contain any data:
image
e. Click Apply and Ok to the usual “Logon as a Service Right granted” message:
image
f. Start the service. It should run without errors.
image
image
The PowerShell way:
a. Start PowerShell.
b. Paste this sample script into a text file:
# Sample script for setting the MSA password through PowerShell
# Provided "AS IS" with no warranties, and confers no rights.
# See
http://www.microsoft.com/info/cpyright.mspx

# Edit this section:
$MSA="contoso\askds$"
$ServiceName="'testsvc'"

# Don't edit this section:
$Password=$null
$Service=Get-Wmiobject win32_service -filter "name=$ServiceName"
$InParams = $Service.psbase.getMethodParameters("Change")
$InParams["StartName"] = $MSA
$InParams["StartPassword"] = $Password
$Service.invokeMethod("Change",$InParams,$null)
c. Modify the highlighted red sections to correctly configure your MSA and service name.
d. Save the text file as MSA.ps1.
e. In your PowerShell console, get your script policy with:
Get-ExecutionPolicy
image
f. Set your execution policy to remote signing only:

Set-ExecutionPolicy remotesigned
image
g. Run the script:
image
h. Set your execution policy back to whatever you had returned in step E:
image
Note: Obviously, I made this example very manual; it could easily be automated completely. That’s the whole point of PowerShell after all. Also, it is ok to shake your fist at us for not having the User and Password capabilities in the V2 PowerShell cmdlet Set-Service. Grrr.
Removal
Removing an MSA is a simple two-part process. Now that you know all the PowerShell rigmarole, here are the two things you do:
1. Use the following PowerShell cmdlet to remove the MSA from a local computer:
Remove-ADServiceAccount –identity
image
2. Optionally, remove the service account from Active Directory. You can skip this step if you just want to reassign an existing MSA from one computer to another.
Remove-ADComputerServiceAccount –Identity -ServiceAccount
image
Group Memberships
The Set-ADServiceAccount and New-ADServiceAccount cmdlets do not allow you to make MSA’s members of groups. To do this you will instead use DSA.MSC or Add-ADGroupMember.
AD Users and Computers method:
1. Start DSA.MSC.
2. Select the group (not the MSA).
3. Add the MSA through the Members tab:
image
PowerShell method:
1. Start PowerShell.
2. Run:
Add-ADGroupMember "" ""
So for example:
image
Note: Use the distinguished name of the MSA; otherwise Add-ADGroupMember will return “cannot find object with identity”. Don’t try to use NET GROUP as it doesn’t know how to find MSA’s.

Limitations

Managed Service Accounts are useful in most service scenarios. There are limits though, and understanding these up front will save you planning time later.
  • MSA’s cannot span multiple computers – An MSA is tied to a specific computer. It cannot be installed on more than one computer at once. In practical terms, this means MSAs cannot be used for:
    • Cluster nodes
    • Authenticated load-balancing using Kerberos for a group of web servers
The MSA can only exist on one computer at a time; therefore, MSAs are not compatible with cluster fail-over scenarios. And authentication through a load balancer would require you to provide a Kerberos SPN of the MSA account-- that won’t work either. Load balancing scenarios include Microsoft software-based and third-party hardware and software-based load balancing solutions. If you’re clustering or NLB’ing, then you are still going to need to use old fashioned service accounts.
A key clarification: You can have multiple MSAs installed on a single computer. So if you have an application that uses 5 services, it’s perfectly alright to use one MSA on all five services or five different MSA’s at once.
  • The supportability of an MSA is determined by the component, not Windows – Just because you can configure an MSA on a service doesn’t mean that the folks who make that service support the configuration. So, if the SQL team here says “we don’t support MSA’s on version X”, that’s it. You have to convince them to support their products, not me :-). Some good places to start asking, as we get closer to the general availability of Windows Server 2008 R2 in October:
TechNet Forums - http://social.technet.microsoft.com/Forums
MSDN Forums - http://social.msdn.microsoft.com/Forums
SQL Support Blog - http://blogs.msdn.com/psssql/default.aspx
Exchange Blog - http://msexchangeteam.com/
SharePoint Blog - http://blogs.msdn.com/sharepoint/
Dynamics Blog - https://community.dynamics.com/blogs/
BizTalk Blog - http://blogs.msdn.com/biztalk_server_team_blog/

Troubleshooting

For the most part MSA’s are straightforward and have easily understandable errors. There are a few issues that people seem to run into repeatedly though:
Error: Error 1069: The service did not start due to a logon failure.

Cause: Typically caused by the MSA being disabled. Use Set-ADServiceAccount to enable your MSA.
Error: Duplicate Backlink. The service account 'AskDS2' has backlinks to computer 'CN=2008R2-F-05,CN=Computers,DC=contoso,DC=com'. This add operation will potentially disable service accounts installed on the other computer. Cannot install service account. Error Message: 'Unknown error (0xc000005a)
Cause: You are trying to associate an MSA with a computer that is already used by another computer. The error notes the server (in this case, 2008r2-f-05) currently using the MSA. Un-associate and uninstall the MSA from the old computer before using it on the new one.
Error: Add-ADComputerServiceAccount : The object could not be found on the server.
Cause: You gave an incorrect identity for the MSA and PowerShell cannot find it. Either it’s been deleted or you typed in the wrong name.
Error: Please enter a valid password.
Cause: You did not remove the password information in the service’s Logon On properties when editing in services.msc. See the setup steps above.
Error: The account name is invalid or does not exist, or the password is invalid for the account name specified.
Cause: This is typically caused by not adding the “$” character to the end of the account name used in the Log On tab in the service’s properties in services.msc. Also, this error is caused by simply mistyping the name of the account or forgetting to add the appropriate domain.

Final Notes and References

For further reading on Managed Service Accounts, check out:

Tuesday, May 5, 2015

Configuring Anti-Virus & Firewall Settings


Anti-virus programs and firewalls can block most or all of the communication to and from a computer. As a result Spiceworks may not be able to communicate with and scan devices on your network. We will separately address the two antivirus and firewall scenarios that could be causing problems, to prevent confusion.
  1. Remote computers you are trying to scan or discover from Spiceworks have the firewall locked down, resulting in either missing computers or a lack of complete data in the Spiceworks inventory.
  2. AV on the Spiceworks host device preventing Spiceworks from running correctly, or the firewall is locked down preventing communication with the remote computers, possibly both. 

 

Remote Computers

Firewall Settings


The following ports and protocols will need to be opened before Spiceworks can collect information from your remote computers:
  • ICMPv4 Inbound and Outbound - This is needed so that Spiceworks can discover the devices on your network; it is more commonly known as the PING command. There are a number of types of ping commands that can be permitted or blocked by various firewalls. Generally, you will want to permit commands 0, 3, 8 and 11.
  • TCP Ports 135 and 445 Inbound - This is needed for Windows Management Instrumentation (WMI) which Spiceworks uses to get detailed information about Windows computers.
  • UDP Port 137 Inbound - This is needed so that Spiceworks can gather information from the Windows Registry.

Windows Firewall


If the devices you are trying to scan with Spiceworks are using Windows Firewall, you will need to configure the firewall to allow Windows Remote Administration.

If you are on a domain you should use Group Policy. Otherwise, those who are on a workgroup or don't want to use Group Policy can add the firewall rules manually from the command line.
 

Manage Windows Firewall via Group Policy


If you are new to Group Policy and need very detailed instructions, please click here. Group Policy is an extremely efficient way to manage your network, so we would encourage you use this how-to to learn to use it.

Group Policy is an effective, centralized way to set and enforce settings across all Windows devices on your network. With a single change on your Domain Controller, you can reconfigure the Windows Firewall settings for all of the devices you want to inventory with Spiceworks.
  • On your Domain Controller, open the Group Policy Management Console (GPMC). You can use gpmc.msc from a command prompt, or find it in Start > Administrative Tools.

  • Edit or create a new Group Policy Object (GPO) and apply it to the appropriate OU. The GPO should enforce these two settings:

  Windows Firewall: Allow remote administration exception
  Windows Firewall: Allow ICMP exceptions

The setting path in Group Policy is:
  Computer Configuration/Administrative Templates/Network/
  Network Connections/Windows Firewall/Domain Profile

 

Configuring Windows Firewall via command line



If you are in a Workgroup environment or choose not to use Group Policy, you'll need to either add firewall rules manually from the command line, or use the Spiceworks Unknowns Assistant.
To manually configure the firewall, use these two commands:
  c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes
  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

Windows XP uses older versions of these commands. If you are using XP, use these two commands instead:
  c:\> netsh firewall set service remoteadmin enable
  c:\> netsh firewall set service remoteadmin enable subnet

Note to XP users: If all of your devices are located on the same subnet as the Spiceworks computer use the "enable subnet" option to limit admin access to the local subnet.

Alternatively, you can use a script created by a Spiceworks user to automate this. This script has proven to be safe and effective in the past, but it's good practice to check it yourself before running to make sure it's right for your environment. You can find it here.

"No rules match the specified criteria" error


Occasionally, some Windows 7 machines return an error on the second ("remote administration") command: "No rules match the specified criteria". The cause of the error seems to be that the remote administration group doesn't exist.
To workaround this error, you'll need to use the older "XP" style command to create the missing group for you:
  c:\> netsh firewall set service type=remoteadmin mode=enable

This returns a warning but does succeed (note the Ok at the end):
  IMPORTANT: Command executed successfully.
  However, "netsh firewall" is deprecated;
  use "netsh advfirewall firewall" instead.
  For more information on using "netsh advfirewall firewall" commands
  instead of "netsh firewall", see KB article 947709
  at http://go.microsoft.com/fwlink/?linkid=121488 .
  Ok.

You can now repeat the second command and it will succeed:
  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

  Updated 3 rule(s).
  Ok.


 

Spiceworks Host Computer


Anti-Virus Settings


The following exceptions need to be setup in the anti-virus program so that Spiceworks is free to run unrestricted.
  • Add the C:\Program Files\Spiceworks directory and all subdirectories to the anti-virus' exclusions list for real-time scanning, this should prevent the anti-virus software from slowing down or stopping Spiceworks from running. The following executable files may also need to be explicitly excluded:

  • C:\Program Files\Spiceworks\httpd\bin\spiceworks-httpd.exe
  • C:\Program Files\Spiceworks\bin\nmap.exe
  • C:\Program Files\Spiceworks\bin\spiceworks.exe
  • C:\Program Files\Spiceworks\bin\spicetray.exe
  • C:\Program Files\Spiceworks\bin\spiceworks-finder.exe
  • C:\Program Files\Spiceworks\pkg\gems\spiceworks_common-x.x.xxxxx\nbtscan\nbtscan.exe
Note: The x.x.xxxxx above is the Spiceworks version number which can be found at the bottom of any Spiceworks page.


Firewall Settings


The following ports and protocols will need to be opened so that Spiceworks can retrieve the backup information from your network devices:
  • UDP Port 69 Inbound - This allows Spiceworks to communicate with your networking hardware to backup/restore configurations via TFTP. 

Monday, May 4, 2015

Reset: LG G2 Mobile




Cache partition

Wipe cache partition

To wipe the cache partition, follow these steps:

  1. From the home screen, tap Apps.
  2. Tap Settings.
  3. Tap General tab.
  4. Tap Storage.
  5. Wait for menu options to finish calculating.
  6. Tap Cached data, then OK.
  7. Wait for the Cached data to clear; depending on size it will take several seconds to complete. When complete the storage screen will refresh and cached data will not be listed.

Note: When you enter Storage again Cached data will appear. Your Cached data has been successfully cleared.

Back to top



Master reset

Master reset from settings menu

A master reset restores the original factory settings and may delete your personal data on the internal storage, such as downloaded content, ringtones, images, apps, and contacts. It does not delete data stored on the SIM card or SD card.

To perform a master reset, follow these steps:

  1. Back up all data on the internal memory. Backup & restore: LG G2
  2. From any Home screen, tap the Menu key.
  3. Tap System settings.
  4. Tap General, scroll to 'PERSONAL.' 
  5. Tap Backup & reset.
  6. Tap Factory data reset.
  7. Tap Reset phone.
  8. Tap Erase everything.
  9. Review the warning, and then tap OK.
    Important: During the master reset, do not remove the battery.


Master reset with hardware keys

A master reset restores the original factory settings and may delete your personal data on the internal storage, such as downloaded content, ringtones, images, apps, and contacts. It does not delete data stored on the SIM card or SD card.

If the device menus are frozen or unresponsive, you can master reset using hardware keys. To perform a master reset, follow these steps:

  1. Back up all data on the internal memory.
  2. Power off the device and ensure it is not connected to any USB cables.
  3. At the same time, press and hold the following keys for 8 seconds:
    • Power key
    • Volume down key
  4. When the LG Logo is displayed, release and then immediately re-hold the Power key.
  5. When the 'FACTORY HARD RESET' screen displays, release the keys.
  6. Press the Power key to reset or one of the Volume keys to cancel.
  7. Press the Power key to confirm the reset. The reset will start immediately.


    Back to top



    Safe mode

    Turn on and use safe mode

    Safe mode allows you to turn on the device with third-party apps disabled. Then you can easily remove all apps that may be causing a conflict or software problem.

    To turn on safe mode and use it to fix app problems, follow these steps:

    1. From any screen, press and hold the Power key.
    2. Touch and hold Power off.
    3. Review the 'Reboot to safe mode' screen, and then tap OK.
      Note: The device will restart and 'Safe mode' appears in the lower-left corner.
    4. Uninstall any third-party apps that gave you problems.


    Turn off safe mode

    To turn off safe mode, follow these steps:

    1. From any screen, press and hold the Power key.
    2. Tap Power off and restart.
    3. Tap OK.

    Mobile Phone: Upgrade LG G2 firmware

    How to flash ROM KDZ Method

    1). Download all The Files Below!

    1) Firmware Files - HERE!
    Or Here LGKDZ.com for your exact match KDZ for your model
    2) Download LG Drivers - LG Drivers Here - 10.9 Mb
    2.1)Verizon Drivers (Verizon Only)LG_VZW_United_v2.11.1.exe - 7.8 Mb

    3) Download LG Flash Tool 2014 tool and extract - LG_Flash_Tool_2014.zip - 3.1 Mb

    4) Enter to Download Mode and plug USB into your PC

    5) Run LGFlashTool2014.exe and do as following pictures :
    (If you cannot run LGFlashTool2014.exe, please install Visual C++ Runtime Library) - Download HERE
    Normal Flash: Flash ROM without losing any data. Only use this when you need to fix system error. Beware of boot loop when flashing ROM that differ from current ROM on your phone or MOD ROM.
    CSE Flash: Choose this option when you need a fresh format. All data will be gone. It's suitable for upgrading or downgrading ROM or simply use this when you need to back to Stock.



    No need to choose desired language, it automatically change to English as a default setting.


    Wait until 100% to complete !



    REMEMBER if you get Bootlooping after flashing perform a factory hard reset!
    Instructions Here: https://support.t-mobile.com/docs/DOC-7590