I'm trying to run an unattended install of SQL Server Express 2014 in a burn package chain and I keep running into problems so I'm looking for advice.
Right now I'm installing it by running the self extracting SQLEXPR_x64_ENU.exe with switches but there are two problems with this method the first being that the extract window doesn't appear in front of my custom bootstrapper UI and second that I have no way to specify the default extraction directory. There is the /X:"C:/Temp" switch but if I use this then the main Setup.exe isn't run upon extract completion.
I tried to resolve this problem by extracting it and including all the required files as a payload group. This works but the compile time and install time are unacceptably slow due to all the small files it has to extract and verify.
I also tried simply referencing the Setup.exe in the extracted folder and left it uncompressed as to have the files in a sub-directory in the root of the installer directory but this to was giving me some startup problems.
I've contemplated installing it with scripts but I feel this is an ugly approach to the problem and I'm avoiding it like the plague but I realize it's possible.
I'd be interested to hear how others have handled this and any advice would be greatly appreciated.
We have worked around this issue using our managed bootstrapper application as follows.
Sql Server 2014 Express SP1 resolved the issue they were having with /qs switch. We can use /qs with /x to specify the extract folder, and extraction proceeds with no user input.
However, as you noted, this just extracts the files, and doesn't start setup.exe. The good news is that the extracted files are still in the folder specified with the /x switch.
In our managed bootstrapper application, we handle the ExecutePackageComplete event. When the Sql Server package has completed (all it did was extract files), we use System.Diagnostics.Process.Start to run the Sql Server setup.exe.
When Setup completes we delete the extract folder.
This isn't what we thought we would do when we started, but at least it's working.
More Information:
As you also mentioned, the progress window for the extracting process opens behind the bootstrapper application window.
I'm not sure what in the bootstrapper is bringing the bootstrapper window back on top. Our UI has a progress bar, so perhaps a progress event is firing after the extracter has started.
We used a timer to give the bootstrapper time to process any events, then we enumerate Process.GetProcesses and look for ProcessName containing "extracting sql". When we find it we use SetWindowPos to bring it to the front.
Related
I have a TFS build process that drops outputs on sandbox which is another server in the same network. In other words, the build agent and sandbox are separate machines. After the outputs are created, a batch script defined within the build template does the following:
Rename existing deployment folder to some prefix + timestamp (IIS can now no longer find the app when users attempt to access it)
Move newly-created outputs to deployment location
The reason why I wanted to rename and move files instead of copy/delete/overwrite is the latter takes a lot of time because we have so many files (over 5500). I'm trying to find a way to complete builds in the shortest amount of time possible to increase developer productivity. I hope to create a windows service to delete dump folders and drop folder artifacts periodically so sandbox doesn't fill up.
The problem I'm facing is IIS maintains a handle to the original deployment folder so the batch script cannot rename it. I used Process Explorer to see what process is using the folder. It's w3wp.exe which is a worker process for the application pool my app sits in. I tried killing all w3wp.exe instances before renaming the folder, but this did not work. I then decided to stop the application pool, rename the folder, and start it again. This did not work either.
In either case, Process Explorer showed that there were still uncollected handles to my outputs except this time the owner name wasn't w3wp.exe, but it was something along the lines of unidentified process. At one point, I saw that the owner was System, but killing System's process tree shuts down the server.
Is there any way to properly remove all handles to my deployment folder so the batch script can safely rename it?
https://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
Use windows systernal tool called Handle v4.0
Tools like Process Explorer, that can find and forcibly close file handles, however the state and behaviour of the application (both yours and, in this case, IIS) after doing this is undefined. Some won't care, some will error and others will crash hard.
The correct solution is to allow IIS to cleanly release locks and clean up after itself to preserve server stability. If this is not possible, you can either create another site on the same box, or set up a new box with the new content, and move the domain name/IP across to "promote" the new content to production
In the Release Management for Visual Studio Deployment log, which can be found under the Details button found when viewing the details of a release, there are a number of columns.
The last three of these are Tool Log, Command Output and Status.
I have never seen anything in Tool Log, but I am in the situation now where I have a component running tests using vstest.console.exe.
Under "Command Output", I see the output from this program as it appears in the console window. However, vstest.console.exe can also be instructed to create a test log (a .trx file), which I would like to view under Tool Log. But I have no idea how to make this happen.
How do I get a log to appear under the Tool Log column?
The answer, it seems, is to set the "Log File Name" in the Tool definition to whatever log file you wish to view (in my case, the .trx file).
This obviously requires that you are using a tool that defines this, or a custom one. Fortunately, I'm using a custom tool.
Your Tool have to copy/create the .trx file to/in the Tool's work directory (%LOCALAPPDATA%\Temp\RM\T\RM\\).
Don't forget to add .trx extesion to Administration -> Settings -> Approved File Extension List.
I had a working SSIS package last week. I came back into the office this morning, opened up the package and tried to open up one of the Data Flow tasks. Double clicking did nothing. I closed the project and reopened it and received an error message that there was a "Catastrophic Error" and that the layout could not be displayed. The Control Flow diagram now only showed my two Sequence Containers.
I made a copy of the dtsx file then went into it manually with a text editor and found that some of the XML was duplicated. I removed the "extra" copy and reopened my package. The empty Sequence Containers are now gone, but I still can't see any of my components. I looked at the Package Explorer and everything is still there, but it's just not displaying in the designer. I was even able to run the package successfully.
Is there any way to rebuild the package so that I can see everything in the designer? Any other suggestions?
Thanks!
I'm not sure why BIDS has decided the layout is junk but you can get around the issue by removing the layout and forcing BIDS to regenerate that information. The graphical layout stuff is a cool idea for conceptualizing how a package is organized but the implementation of storing that information, serialized XML inside XML, is pants.
There are various articles available about how to remove the XML, but this is a more recent example of how to use do this. http://joshrobi.blogspot.com/2012/04/editing-existing-ssis-package-via-ezapi.html
As always, ensure you have a good copy of the package before editing the XML directly.
Do you have a backup of your package - try and restore that to another location first to make sure that is not corrupted.
How are you accessing the package, are you connecting remotely to a server hosting SSIS, or are you using tools located locally on the server?
I've encountered issues when trying to access packages across networks before.
Also, as a word of warning it's not good practice to edit package contents before carrying out further diagnosis!
I think there must be an easy solution to my problem but I can't figure it out. We're using NServicebus in a windows service and we have configured it to use log4net for logging, in code we have this:
SetLoggingLibrary.Log4Net(log4net.Config.XmlConfigurator.Configure);
Configure.With().Log4Net().....
So far so good. The problem is that NServicebus still creates it's own logfile, named "logfile" placed the same folder the application is run in, i.e. amoung the binaries. In our development and test environments where we reinstall and restart the service frequently this soon polutes the binaries folder with a lot of logfiles as a new is created each day (the old one from a previous date is renamed to for instance: logfile2012-02-28).
In the config-file of the service we have these lines:
...
<section name="Logging" type="NServiceBus.Config.Logging, NServiceBus.Core" />
<Logging Threshold="OFF" />
so all logfiles are empty but how do we stop them from being created or at least have them created in a separate log folder?
Thanks
Christian
Your calls to SetLoggingLibrary and .Log4Net() are conflicting with each other, and probably also with the profiles (if you're using NServiceBus.Host.exe).
Have you looked through the docs?
http://docs.particular.net/nservicebus/logging/
I have a VB6 app that I've been selling for over 12 years. Sometimes I have users that have a hard time getting the app to run. The data writes are going into /My Documents so nothing but the installation files (EXE, etc.) are going into C:\Program Files (or C:\Program Files (x86)).
The fix to their problem is to start the app, even though it appears hung, then show the task manager, view processes, right-click my app's process and uncheck UAC Virtualization. Then I have them repair the installation and all is fine.
Why is my process getting put under UAC Virtualization and how do I prevent this from occuring? I also use InstallShield 2010 Professional to create the installation, I'm not sure if it's related to the installer or the app itself.
To prevent virtualization, add a manifest to the application. Whether you say asInvoker or requireAdministrator, you won't get virtualization any more. I am guessing asInvoker will be better for you since the app works fine without elevating.
You can just put foo.exe.manifest in the same folder as the exe, or embed it, which has some tricky stuff like making the manifest a multiple of 4 bytes long. This question covers some gory details of embedding.