A blog with focus on Windows 10 and cloud <solutions
RSS icon Email icon Home icon

  • Application services not migrated when upgrading from one Windows 10 build to another when path contain forward slashes

    Posted on February 14th, 2017 By Andreas Stenhall + No comments

    It seems that some applications (none mentioned and none forgotten) create services where the path to the service is written with forward slashes. The migration engine in Windows 10 does not recognize this as a valid path and therefore do not migrate those services and they are thereby missing after upgrade.

    The following can be found in the setupact.log (located in C:\Windows\Panther) after upgrading Windows 10 to a new build:

    2017-02-07 16:07:42, Info       [0x08056f] MIG    Start processing unit="Services"
    2017-02-07 16:07:42, Warning               MIG    CAddSystemServicesExpander::ExtractImagePath: Failed to extract file path from APP_Service::ImagePath=["C:/Program files/Vendor/Product/APP_Service.exe"]

    The solution is to make sure the application is installing the service with a path that contain backslashes instead of forward slashes.

  • HOW TO: Handle user group policy settings in multiple OS environments

    Posted on December 22nd, 2011 By Andreas Stenhall + 1 comment

    This is a very common question and one that I would say all companies migrating to Windows 7 has experienced. The scenario is how do we handle user group policy settings when we have multiple operating systems such as Windows XP and Windows 7 or in the future also introduce Windows 8?

    First I strongly recommend that you do not reuse the user configuration for Windows XP for Windows 7. Group policies tend to grow over time and at most customers I have encountered a lot of rubbish in the old configuration. Starting over and migrating only what is needed minimize the risk for problem and makes the configuration slicker and more easy to manage in the long run.

    But how do we make sure that users get one configuration when they log in to for instance Windows XP and another configuration when they log in to a Windows 7 or Windows 8 machine? Well, let’s have a look at the options including pros and cons followed by recommendations from the field.

    1. Security group filtering

    • Pros:
      – Require no change in OU structure/move of users.
    • Cons:
      – Requires a lot of management and make it hard to administer.

    2. Separate users into a new and old OU

    • Pros:
      – Easy to do if you have very few users and no dependencies to other services or applications.
    • Cons:
      – Not a manageable solution in an environment with many users.
      – There are often apps or services that rely on the users being in a certain OU which is making it hard to move users without affecting other services.

    3. WMI filters

    • Pros:
      – Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
      – A longterm investment in making it easy to introduce new operating system versions.
      – Quick determination (WMI is often known to be real slow but this particular query is not performance intensive).
    • Cons:
      – Need changes for existing environment, i.e. for instance Windows XP user configuration.
      – Could make group policies not being applied due to problems with WMI repository or related services.

    4. Loopback processing

    • Pros:
      – Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
      – Very reliable solution.
    • Cons:
      – If not Replace mode is used you need to handle current configuration.
      – Might become a mess to troubleshoot and maintain if naming and config is not done consistent and clear.

    Recommendations from the field

    In my professional opinion the only real alternatives are WMI filters or loopback processing and sometimes I recommend WMI filters for separating user settings depending on what operating system they are logging in to and sometimes I recommend loopback processing. It depends on the environment and needs for the customer. Many times moving the user accounts around is not an alternative but consider that a very good alternative if possible to accomplish.

    How do I implement it in my environment?

    1. WMI filters

    In the Group Policy console you create multiple WMI filters for for instance Windows XP and Windows 7. You then set each WMI filter respectively on each GPO containing user settings for each operating system. NOTE: Always test it out before applying this configuration to your existing environment. Also note that this does not affect performance to any noticeable amount of time.

    Windows XP:

    SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.2%" AND ProductType ="1"

    Windows 7:

    SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.1%" AND ProductType ="1"

    Windows 8:

    SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.2%" AND ProductType ="1"

    Basically the version is the OS version as we know it and the ProductType=1 means that it is a client operating system.

    So you will end with for instance one GPO named “User Configuration – Windows 7” which have the WMI filter for Windows 7 machines set and one GPO named “User Configuration – Windows XP” which have the WMI filter for Windows XP set.

    2. Loopback processing

    A prerequisite for using loopback processing is that you keep computers in separate OUs, for instance XP computer accounts in one OU and Windows 7 computer accounts in another OU.

    You then create GPO objects in the OU for Windows 7 in our example and configure the user settings there. As I think you should always separate Computer and User configuration GPO:s I would say that you in a Computer configuration policy in that same OU set this setting for the user settings to be applied when users log into Windows 7 machines:

    Policies – Computer configuration – Administrative templates – System – Group Policy and there set “User Group Policy loopback processing mode” to Replace or Merge, depending on what you want to achieve and how you want to handle your current configuration. Replace mode is recommended as you will have a hard time maintaining and troubleshooting the configuration otherwise.

    Done! When users log on to your Windows 7 machines they will get the user settings you have defined in the user configuration GPOs located in the Windows 7 machines OU in our example.

  • Gain access to Operations and Application Management in SharePoint in SBS2008

    Posted on March 3rd, 2009 By Andreas Stenhall + No comments

    Some time ago I migrated a client’s Small Business Server 2003 to a Small Business Server 2008. When migrating their WSS 2.0 SharePoint from the old server to the new one I ran into some problems. I just could not get access to the Operations or Application management in SharePoint Central Administration, with the  below event logged.

    Log Name:      Application
    Source:        ASP.NET 2.0.50727.0
    Date:          2009-02-26 13:23:42
    Event ID:      1314
    Task Category: Web Event
    Level:         Information
    Keywords:      Classic
    User:          N/A
    Computer:      CONTOSOSRV02.Contoso.local
    Description:
    
    Event code: 4007
    Event message: URL authorization failed for the request.
    Event time: 2009-02-26 16:21:50
    Event time (UTC): 2009-02-26 15:21:50
    Event ID: 0087e3fc2a3440178e6a801602c514f7
    Event sequence: 113
    Event occurrence: 6
    Event detail code: 0
     
    Application information:
        Application domain: /LM/W3SVC/1899589246/ROOT-1-128801351457937683
        Trust level: WSS_Minimal
        Application Virtual Path: /
        Application Path: C:\inetpub\wwwroot\wss\VirtualDirectories\4721\
        Machine name: CONTOSOSRV02
     
    Process information:
        Process ID: 7888
        Process name: w3wp.exe
        Account name: CONTOSO\Administrator
     
    Request information:
        Request URL: http://contososrv02:4721/_admin/operations.aspx
        Request path: /_admin/operations.aspx
        User host address: ::1
        User: CONTOSO\tempadmin
        Is authenticated: True
        Authentication Type: Negotiate
        Thread account name: CONTOSO\tempadmin

    After doing som troubleshooting I got everything working by editing the web.config file of the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\ADMIN directory. I simply added the line below to the file, saved it and then I could access the Operations and Application Management of SharePoint Central Administration.

    <allow roles="CONTOSO\WSS_ADMIN_WPG" />

    Case closed!