Jump to content

Nazgul

Member
  • Posts

    144
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Netherlands

Posts posted by Nazgul

  1. From http://www.microsoft.com/technet/community..._feb15_sql.mspx

    Q: Will there be a Slip streamed SP4 Install package for SQL 2000 to ease the installation of SQL 2000 on Windows 2003?

    A: There will NOT be a slipstreamed version of SQL 2000 SP4 - except for MSDE per usual. SP4 is still Installshield-based as was our original SQL Server 2000 product. SQL Server 2005 (aka Yukon) will be MSI based and we are working to provide slipstream SPs on that platform thanks to the benefits of MSI. MSDE users will have a full version (SQL 2000 + SP4) for their MSDE installation in both MSM and MSI format.

  2. It is mentioned on that page, but there is an error in that information:

    For unattended installations of Windows XP SP2 or later versions, you can use the Unattend.txt file to pre-populate a specific DEP configuration. You can use the OSLoadOptionsVar entry in the [Data]section of the Unattend.txt file to specify a system-wide DEP configuration.
    This states that you can use the OSLoadOptionsVar entry to set DEP settings during unattended installation.

    The only problem is that they state that it should be in [Data] while it should be in [setupData].

    This article on Microsoft Technet specifies the different settings you can provide.

  3. You could try parsing the System Eventlog for events with the 7035 or 7036 Id, issued by the Service Control Manager to determine when services where started/stopped.

    You can also use the sc query command from a command prompt to get a list of currently running services.

  4. Two things that come to mind:

    - Did you change the SetupSourcePath in txtsetup.sif (this file is also present in your bootfolder!)

    - Try using a SP2 bootfolder. There are a lot of tools out there that will help you create one (like this one)

  5. Could you verify that the security option "Network security: LAN Manager authentication level" is set to "Send NTLMv2 response only\refuse LM".

    You can also verify this by looking at the following registry key:

    HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel=?

    Where the number at ? should be 4 (or lower) If it's 5, this could be your problem.

  6. A small quote from Microsoft Windows Internals 4th edition:

    Using the /3GB switch increases the size of the user process address space from 2 GB to 3GB (and therefore reduces the size of system space from 2 GB to 1 GB) Giving virtual-memory-intensive applications such as database servers a larger address space can improve their performance. For an application to take advantage of this feature, however, two additional conditions must be met: the system must be running Windows XP, Windows Server 2003, Windows 2000 Advanced Server, or Datacenter Server; and the application .exe must be flagged as a 3-GB-aware application (applies to 32-bit systems only).
    There aren't a lot of programs out there that are compiled with the correct flags to support a 3 GB address space, so this setting doesn't really have that much effect. It can even reduce performance, because system space is reduced to 1 GB, while most applications can only use the 2 GB of user process address space, thus in theory wasting 1 GB of virtual memory.

    (The only application i know for sure that are compiled with the correct switches are IIS and MSSQL)

  7. The message tells you that there's something wrong with txtsetup.sif, so the first question you have to ask yourself is: Did I change that file?

    If so, what changes did you make and could you have made an error in them?

    Try comparing that txtsetup.sif with the original one and see what differences there are. And if there are differences, are they're all expected diferences. (You can use fc.exe to compare files or get a hold of a GUI based file comparison tool like WinDiff.exe)

  8. I don't know if there is a method of doing that, but even then I wouldn't use it.

    There are a lot of valid reasons why you don't want Windows to use the entire RAM before starting to swap.

    I'll give an example:

    You have a number of programs running which use the entire RAM (and probably some swap space). When I start a new program Windows will first have to swap data from memory to swapspace and then load the new program into RAM before starting the new program.

    If we don't allocate all RAM we get:

    The new program gets loaded into RAM at once and starts. Windows then schedules a task to move some non-frequently used data from RAM to swapspace (at a slightly lower priority) to get the RAM usage under a certain threshold.

    Although the same amount of date gets moved to swap the second scenario appears to run faster for users because their applications start running earlier in the process.

×
×
  • Create New...