Jump to content

ProClub

Member
  • Posts

    25
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Hungary

About ProClub

  • Birthday 08/16/1984

Contact Methods

  • Website URL
    http://

ProClub's Achievements

0

Reputation

  1. Great, guys, that's something to get started with. If I'm done, I'll let you know!
  2. O well. I guess, I'll just have to write it. Would anyone else be interrested in such a script? Or maybe a generic script runner service? I'd be happy to help someone else out too if I'm writing this... I just did a little digging and guess what I found: http://support.microsoft.com/kb/q137890/ It seems I can run a regular application (or in this case command line script) as a service. There is only the matter of scheduling. I somehow need to have that service start after login. But I guess, that's an issue I can fix. Maybe I don't have to write a service after all. I'll check back and tell how it worked out.
  3. What do you mean by autologon? Wouldn't that be a security crater? Giving my users a way to have an admin account? Even if I have Windows not load the UI, they still can use Ctrl+Shift+Esc, new task to run any app they like. So, there is no other way than writing a service... sigh... Never mind. SMS is a bit too expensive for a high school, so I guess, I'm just going to write it...
  4. Hi there! I made a fancy unattended install and now wish to have my systems remotely maintained. For this reason I created a network share and a script, that checks for new "updates" on this share. If it finds a new script to be run (AKA update), it runs it. This can be used for a variety of tasks, making system wide updates a piece of cake. SMS isn't free, so I'd prefer to use this solution. However, I've run across a major problem. At the time, GP startup scripts run, there is no network yet. At thetime, shutdown scripts run, the network is allready offline. Logon/off scripts won't do it because of user right problems. Manually starting the network service via NET START won't work, because the service is started, but I still get an error for NET USE. The only solution I can think of is writing a service to download update packs while the user is loged in and then run them at shutdown time. The question is: is there ANY way to have network support with SYSTEM rights WITHOUT writing a service? Thanks in advance J The script would be: NET USE P: \\192.168.1.3\install /USER:myusername mypassword FINDSTR /V /I /G:C:\WINDOWS\updates\updates.lst p:\update\updates.lst >%temp%\updatelist.txt FOR /F %%I IN (%temp%\updatelist.txt) DO p:\update\%%I.cmd del /Q %temp%\updatelist.txt COPY /Y p:\update\updates.lst C:\WINDOWS\updates\updates.lst NET USE P: /DELETE
  5. If you need to install some stuff, you might alternatively do it in a startum/shutdown script implemented by group policies. I recommend shutdown, because the program will be ready for use next time the computer starts up. There will be no rights problems, because these scripts run as SYSTEM. (Logon/logoff scripts run as user!)
  6. Hi there! Maybe you'll find some use in what I have learned. So, I work on an unattended install for a WinXP deployment in a 50 computer public access environment. At least, as far as compulsory login school usage is public. We had the problem of retained cached roaming profiles and fragmented hard drives for years, so I moved profiles, temp directories and the page file to drive d: and wipe the whole thing every startup. Ok, not everything, default user profile and some stuff stays, but basicly, that's it. I intend to do a write protection on C: except for SYSTEM. At shutdown time, a script will run and check a local update distribution server if I put some new fancy updates on it for install. If there are some (for whatever application) the script displays a message to the user and installs the updates. This way, I intend to keep the end-user computers up and running. Hope, this helps someone.
  7. This is, because Daemon Tools installs a driver for the "fake" drives. So, in other words, Windows will not load/unload the drivers until you restart. They are in use. So, no Plug and Pray. You'll have to do a restart, there's no other way. Except, if you want to recode Windows' driver handling mechanisms. I would advise against it.
  8. I'm glad it helped. I intend to post more in detail if there is something unclear. Just let me know.
  9. There is also a switch to run the script async. Tried that yet?
  10. Hello everyone! After having a hard time getting BartPE to work as intended, I decided to write a short tutorial for those coming after me. So, let's get started. 1. Download BartPE and install it. I trust, this does not require further explanation. 2. Create your unattended CD/DVD. 3. Take your i386 folder from your original distro dir and put it into a newly to create xp directory. So your dir should be: distrodir\xp\i386. This is, because BartPE uses the i386 directory for Windows components. 4. Create a new i386 directory in your distro dir. Inside, create a System32 dir. Inside that, we will put our config files for partitioning and stuff. 5. Put your $oem$ folder INSIDE distro\xp\i386 6. Create your config files. Mine look like this: autorun1.cmd: DISKPART /s partinfo.txt FORMAT c: /fs:ntfs /Q /V:Local /Y FORMAT D: /fs:ntfs /Q /V:Local /Y FOR %%i IN (D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF EXIST %%i:\AUTORUN.INF SET CDROM=%%i: %CDROM%\xp\i386\winnt32.exe /syspart:c: /tempdrive:d /unattend:"%CDROM%\xp\i386\winnt.sif" /makelocalsource partinfo.txt: SELECT DISK 0 CLEAN CREATE PARTITION PRIMARY size=2048 ASSIGN ACTIVE CREATE PARTITION EXTENDED CREATE PARTITION LOGICAL ASSIGN EXIT 7. now, create your BartPE project and test it. It should work fine. Note, that this has a positive side effect. Since a local source is created, you may take your CD out if there is no software to be installed from it. This should be the hard part. Feel free to extend this tutorial.
  11. You _could_ use the group policy editor to define a startup script. No login, SYSTEM rights. You don't NEED a service to do it. Start>run>type gpedit.msc>ok Hope, this helps.
  12. This is very cool. But I allready figured it out myself. I want to run diskpart _before_ I even start copying files. I specified the profile directory to d: for example. So if I create d: in the guirunonce part, my system will be somewhat unusable. That's why I said, I'd like to have it in the txtsetup part.
  13. I don't know about wsname, the doc states it uses the DNS name. What if the DNS name is something like computer007.mydomain.tld? My method sets the computer name to computer007. What about wsname?
  14. I do HAVE a local update server. As far as software is conserned. Or can I use the local wupdate server method to deploy software updates? However, I found a means to install my software. I use a local policy to run a shutdown script. This should work since software runs with SYSTEM rights.
  15. Hi there! I wrote a little script to get the domain name of my local computer on the network. Since this was somewhat of a headache for many, so I post my script here. Note: this runs on WinXP only, as far as I know. Feel free to optimize it. It's a Q&D script. ipconfig | find "IP Address" > ip1.txt for /f "tokens=1-2 delims=:" %%i in (ip1.txt) do echo %%j > ip2.txt del ip1.txt for /f "tokens=1-4 delims=. " %%i in (ip2.txt) do ( nslookup %%i.%%j.%%k.%%l >ns.txt set IP=%%i.%%j.%%k.%%l ) del ip2.txt for /f "skip=2 tokens=2 delims=: " %%i in (ns.txt) do if not %%i==%IP% set DNS=%%i del ns.txt The DNS name is stored in %DNS%. You can use it with compname if you like. If you want to truncate it to the computer name, use: for /f "delims=. tokens=1" %%I IN ("%DNS%") DO set ComputerName=%%I afterwards. Note, that the desired computer name will be set in the %ComputerName% variable. Hope, this helps. J
×
×
  • Create New...